A co-worker in the small start-up I work at writes (C++) code like this: // some

Question

A co-worker in the small start-up I work at writes (C++) code like this:

// some class
class SomeClass {

    // c'tor
    SomeClass();

    // d'tor
    ~SomeClass();

    // some function
    void someFunction(int x, int y);
};

// some function
void SomeClass::someFunction(int x, int y) {

    // init worker
    m_worker.init();

    // log
    LOG_DEBUG("Worker initialized");

    // find current cache
    auto it = m_currentCache.find();

    // flush
    if (it->flush() == false) {

        // return
        return false
    }

    // return
    return true
}
This is how he writes 100% of his code: a spacer line, a useless comment which says nothing other than what is plainly stated in the following statement, and the statement itself.

This is absolutely driving me insane.
A simple class written by him spans 3 times as much as it's supposed to, It looks well commented but the comments contain no new information. In fact the code is completely undocumented in any normal definition of "documentation". All of the comments are just a repetition of what is written in C++ in the following line.

I've confronted him several times about it and each time he seems to understand what I am saying but then goes on to not change his coding and not fix old code which is written like this. I've went on and on again and again about the distinct disadvantages of writing code like this but nothing get through to him.

Other co-workers doesn't seem to mind it as much and management doesn't seem to really care.

What do I do?

Explanation / Answer

Dealing with Douchebags: Your Boss's Job
Not yours. Learn to either ignore him, or report him with evidence that his attitude not productive and that his coding guideline is detrimental to the codebase's quality.

Dealing with Existing Bad Code: Your Continuous Delivery Pipeline's Job
Set up Continuous Integration system to do periodic builds.
Set up a continuous integration game to attribute good and bad points on broken builds.
Set up continuous inspection system to calculate metrics on the codebase and flag obvious violations.
Set thresholds in both systems so that some builds will be marked as FAILED if some thresholds are way too off the charts.
Show pretty graphs to managers.
Gradually hunt down crap code and axe it.
Refusing New Bad Code: Your Team's Job
Set up regular peer-reviews for large features;
Open tickets for required changes;
Implement pre-commit hooks that you can buy to similar analyzers as for the CI systems, and rejects commits that are also off the charts fugly.
Note: This is all a bit petty and I'm definitely NOT saying that I believe defect counts, code metrics and so forth are necessarily a good indicator of a coder's and a codebase's virtue, but it helps to get the point across and bring, enforce and maintain good habits.

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.