4 ms·
Lets see. I think most people agrees on the bad of over-commenting or wrong-commenting. But I would like to review your reasons: "1. They tend to encourage b
by txutxu 13y ago
Lets see.
I think most people agrees on the bad of over-commenting or wrong-commenting.
But I would like to review your reasons:
"1. They tend to encourage bad code."
I don't think so. I've seen great comments, even if it's not a cool topic.
There is some factors which may change the quality of a comment, a lot of them are cosmetics, but there are other like: the capacity of the programer to empathise with future maintainers/users and think on them, the capacity of the programer to redact good comments and think interesting messages to people following the code, the committing level of the programer with the future of the project, etc...
But I don't see how comments encourage bad code. People can make bad code, and bad comments, and good code, and good comments.
"2. We spend more time writing and maintaining them."
If a comment is making you loose time, it's a wrong comment. All you use programming is to save time.
The reasons you give there, point more to poor designs or inconsistent project managements.
"3. Comments are not testable/verifiable."
All is testable, hint: search in metacpan for: test pod
You can introduce deprecation policies, in your code, in your tests and... in your comments. Check for validity, spell, dead-links, text matchings, etc... I don't know why you assert you cannot.
"4. They are less reliable than the documented code"
That points to wrong comments.
If a comment is wrong, is wrong, the same as if a line of code is wrong, it, is, wrong.
If a comment is in the code, should be because it helps to the usage (typically the maintenance) of the code.
In the case of libraries (typical usage of the code: reuse), it's usual nowadays that what you find in comments, is the metadata needed to build the library documentation.
I think both cases of comments, internal maintenance and public "face" of the code, imho should be always as reliable as the code lines if we want to treat seriously a project. I know it's not, but that's just lazy/ego/copy people.
"5. Some comment styles can fill a lot of screen space"
That's not a reason to not use them. If they fill screen space with _useful_ information.
Your programming oriented text editors, eventually can (un)collapse comments.
So, that is my review to your reasons.
I could have write:
0. On bash, long comments slow down execution (measurable at big scale).
1. Wen I code for myself, I don't comment.
2. As we now there is not going to be time to document this project, we just "do it".
That are valid reasons for me.
Best regards.