[arctangent]

I understand the point of the exercise and I can see that an individual coder might gain some benefit from this.

However, in a professional environment you would expect that the lead developer(s) had already given this stuff a lot of serious thought and enshrined it in a coding standards document for every member of the team to follow.

[casenelson]

I have a copy of Code Complete on my desk, it is 915 pages long. The techniques in there have been gathered from years of experience and research. There's no way I'll ever absorb all of the knowledge in there, but some of it may stick. When I write code I might unconsciously pick out a technique from the book, yet later on I'll miss the opportunity to apply the same technique again. If I better understood what I was doing the first time, I'd be more aware of it later.

Now, you're right, the easiest questions (as in the article) to answer can and should be encoded in standards document. But there are many many questions to ask and some are highly dependent on context and don't belong in standards documents. Maybe some of the existing standards that you thought you understood are really just there by convention and could be improved.

[apaprocki]

A good idea is to check for certain style issues which you want to enforce and are easy to catch at checkin time. You can enforce things like no real tabs, line width, no trailing spaces, etc and make the person checking in the code get rid of it. Usually once it winds up in VCS[1], it is harder to go back and clean it up. People make mistakes all the time, and tools are scriptable.

[1] Or do it at merge time if your setup involves pushing to a "work" repo which is merged to the real codebase later.

[pmiller2]

I'd argue that if it's so easy to check you can do so with a commit hook, you should also automate fixing it. If you're using C, C++, C#, or Java, you can do this with astyle pretty easily, for instance.