Along these lines, I made a little program which yells at me whenever I have too many lines of code without a comment, or too many lines in a single file. I've found it quite helpful not having to actively think about that sort of maintenance stuff.
Regarding comments, I really liked a technique Martin Fowler talked about in Refactoring.
Whenever he feels the need to comment, he extracts the commented block into a new method and gives it a name that explains the purpose - instead of the comments.
The result is code cut into small self-explaining blocks that reads pretty much like a sentence.
I tried to follow it these last weeks and IMO it works great.
Yeah, I followed that advice at one point. But I find in practice a plain English comment can be much more helpful than a function name. For example, from the code I linked:
# Check too many lines. Count number of lines without a comment.
If I were to turn that into a function name I would either have one long ass function name or (more likely) I would cut out several words and lose a lot of readability and clarity.
I think it's a bit too long, yes. I prefer around 10-15 characters for function names. Also, you've lost a lot of readability with that camelCase. Also, the "Check too many lines." part wasn't superfluous -- I had a separate check for too many total lines before I count the number of lines without a comment -- and that part of the comment has been lost.
I am thinking along the same lines. If something is not "policed", then it won't happen in the long run as interest shifts. Includes programming practices, testing coverage and the usual stuff. And more effective to automate such things and spend code reviews on interesting issues, not "punctuation".
I wonder if anyone has examples for or against of running such checks against your codebase? I can imagine some horror stories of how those tools would slow down all useful work. But some success stories? I guess I have to try on myself first :)
