4 ms·
I feel like this translates to "lazy* developers are a problem" rather than "comments are a problems". Snarkily, how lazy* do you have to be to not even delete
by RangerScience 10y ago
I feel like this translates to "lazy* developers are a problem" rather than "comments are a problems".
Snarkily, how lazy* do you have to be to not even delete comments you make stale?
* And not as in the virtues of programming lazy.
- sqeaky 10y agoIt seems to me this is more of a knowledge issue or even a code/discoverability issue. The closer a piece of documentation is to the code the more likely it is to be updated. External manuals always become stale and comments in C headers are more likely to be stale than comments next to the implementation in C source files (or in any language that doesn't even have that distinction). Comments directly next to complex formulae or other technical BS are most likely to be correct. Some learn that then suggest getting rid of all comments or putting comments throughout all the code, but if we look at it another can can infer that some of it is code structure problems. A 2k line class with 200+ line methods with comments at the beginning of each method is more likely to have stale comments that any number of tiny classes with 10 line methods. Then comments on a 10 line method are more likely to be read too, because they need to describe less. Ideally they just add the "why" to the "what" the method's name provides. If the whole method and all the comments fit on the same screen then the dev ignoring it must be truly lazy.