Duplicate
A Developer I work with had some things to say about commenting that were interesting to me (see below). What is your personal approach/take on commenting?
"I don’t add comments to code unless its a simple heading or there’s a
platform-bug or a necessary work-around that isn’t obvious. Code can change and comments may become misleading. Code should be
self-documenting in its use of descriptive names and its logical
organization – and its solutions should be the cleanest/simplest way
to perform a given task. If a programmer can’t tell what a program
does by only reading the code, then he’s not ready to alter it.
Commenting tends to be a crutch for writing something complex or
non-obvious – my goal is to always write clean and simple code.""I think there a few camps when it comes to commenting, the enterprisey-type who think they’re writing an API and some grand code-library that will be used for generations to come, the craftsman-like programmer that thinks code says what it does clearer than a comment could, and novices that write verbose/unclear code so as to need to leave notes to themselves as to why they did something."
There’s a tragic flaw with the ‘self-documenting code’ theory. Yes, reading the code will tell you exactly what it is doing. However, the code is incapable of telling you what it’s supposed to be doing.
I think it’s safe to say that all bugs are caused when code is not doing what it’s supposed to be doing :). So if we add some key comments to provide maintainers with enough information to know what a piece of code is supposed to be doing, then we have given them the ability to fix a whole lot of bugs.
That leaves us with the question of how many comments to put in. If you put in too many comments, things become tedious to maintain and the comments will inevitably be out of date with the code. If you put in too few, then they’re not particularly useful.
I’ve found regular comments to be most useful in the following places:
1) A brief description at the top of a .h or .cpp file for a class explaining the purpose of the class. This helps give maintainers a quick overview without having to sift through all of the code.
2) A comment block before the implementation of a non-trivial function explaining the purpose of it and detailing its expected inputs, potential outputs, and any oddities to expect when calling the function. This saves future maintainers from having to decipher entire functions to figure these things out.
Other than that, I tend to comment anything that might appear confusing or odd to someone. For example: ‘This array is 1 based instead of 0 based because of blah blah’.
Well written, well placed comments are invaluable. Bad comments are often worse than no comments. To me, lack of any comments at all indicates laziness and/or arrogance on the part of the author of the code. No matter how obvious it is to you what the code is doing or how fantastic your code is, it’s a challenging task to come into a body of code cold and figure out what the heck is going on. Well done comments can make a world of difference getting someone up to speed on existing code.