I find that the commonly touted opinion that comments should only reflect why, and avoid all duplication; is misguided. The only places where I will elaborate on why is where I can see obvious room for improvement but I'm still waiting for the bigger picture to stabilize, or I'm adding a dependency that I'm not really happy with. Otherwise my comments mostly express the intent of the code in regular prose and have to…
“My Code is Self-Documenting”
31–40 of 100 posts
Re: “My Code is Self-Documenting”
#32I think the Uncle Bob quote is good: "Code comments are not the Schindler's List. They're not pure good." If a line of code has a comment attached to it, the reader needs to understand both the code and the comment. The comment is written in natural language. There are multiple ways of understanding it. It must be written with great care so that people reading it don't misunderstand it. Otherwise it will likely just…
The idea would be that the function names are so good that one does not need to read the function contents, right?
But some things are complicated and may not be expressible with the function name alone.
That's why people write comments. To help readers understand the code.
Let's say I am implementing some algorithm. I may mention the performance characteristics in the comment. Or I may let the readers dig into the code to find out what they are. Seriously, please don't follow "no comments" rule dogmatically.
Re: “My Code is Self-Documenting”
#33Earlier quoted context omitted.
Well this seems like a problem with code reviews (or lack of), rather than with the comments themselves.
It's a matter of incentives. Business folks don't care about comments unless they have a dev background. Your options are then to focus on the incentives present in the situation, or materially harm your own life and well-being by working extra hours to make up for your management's inability to manage.
All they care about is that the code works, and that features can be delivered on time.
That second part "delivered on time" includes maintaining the comments along with the code since it makes the code more readable, and eases future changes. If Management doesn't give you time to write maintainable code (which includes keeping comments in sync with the code), then you may as well start looking for a new job because the technical debt is going to pile up and it's going to get harder and harder to meet deadlines.
Re: “My Code is Self-Documenting”
#34Yet this may just indicate that the code is complex and therefore required comments and contains bugs.
In any case, high comment density is a code smell.
Re: “My Code is Self-Documenting”
#35But just yesterday I came across a particularly good comment in an else block, that summarized the story of "how could we have gotten here", and it involved far-flung failures and not so obvious interactions. Very informative to have that right there.
Re: “My Code is Self-Documenting”
#36Best of both worlds or something.
Re: “My Code is Self-Documenting”
#37Earlier quoted context omitted.
As others have said.. Code doesn't depend on variable/function names either. Yet you don't argue they fall out of sync, you simply update them. And this should be done for comments, too.
Code does depend on variable/function names. When you change the name at the definition, your code fails to compile until you also change the name at each usage. This is not true of comments. If we could make outdated comments produce compilation errors, we would live in a wonderful world :)
I really hate it when the compiler ignores my comments.
Re: “My Code is Self-Documenting”
#38I think the Uncle Bob quote is good: "Code comments are not the Schindler's List. They're not pure good." If a line of code has a comment attached to it, the reader needs to understand both the code and the comment. The comment is written in natural language. There are multiple ways of understanding it. It must be written with great care so that people reading it don't misunderstand it. Otherwise it will likely just…
No, the reader must not need to read the function to understand how it works. The idea would be that the function names are so good that one does not need to read the function contents, right? But some things are complicated and may not be expressible with the function name alone. That's why people write comments. To help readers understand the code. Let's say I am implementing some algorithm. I may mention the perfo…
If I have a function and I need to understand _how_it works_, that is, how does it implement some algorithm, of course I have to read every single line of code to understand how it works!
If the function is named "quicksort", for example, and I suspect it has a bug, I really have to read it to understand whether it implements the quicksort algorithm correctly.
Re: “My Code is Self-Documenting”
#39Earlier quoted context omitted.
As others have said.. Code doesn't depend on variable/function names either. Yet you don't argue they fall out of sync, you simply update them. And this should be done for comments, too.
Code does depend on variable/function names. When you change the name at the definition, your code fails to compile until you also change the name at each usage. This is not true of comments. If we could make outdated comments produce compilation errors, we would live in a wonderful world :)
Doxygen supports documenting function parameters, C++ template parameters, return values then Doxygen and Clang can tell if the name listed for some of those things doesn't match the actual code or if a certain kinds of comments are missing. This won't tell you the documentation is wrong, but it would stop you from adding or removing a function parameters while ignoring documentation comments entirely.
If you want to go crazy you can write Clang plugins using LibTooling and run and code you want and analyze the comments any way you choose.
Re: “My Code is Self-Documenting”
#40> Code comments document the why, not the how. I disagree. The _what_ is what your comments should tell me. The contract, and its preconditions and postconditions. Nothing more, nothing less.