Comment by rustystump
12 hours ago
as others have pointed out, the reality is not this. id go further and say almost all comments are evil.
Excuse me if I am harsh, read the damn code. If you do not understand the language, that is a skill issue. If the code is confusing, then the code is bad and no amount of comments will ever change that. Professional engineering isnt an intro to databases class.
I am excusing language conventions which may have comments as part of its idiosyncratic nature.
"If the code is confusing, then the code is bad and no amount of comments will ever change that."
I've worked on a lot of terrible legacy code in my career and I'm very thankful for the comments that others have left. This is becoming less necessary now that LLMs can explain a project, but comments have historically been a godsend in bad code.
Clean code considered harmful.
No, really: comments should be telling you what the code shouldn’t or physically can’t. Code is for execution and the exact details of what and how; it has no business knowing why or why not and that’s where comments are required.
If you are only encoding intent through "self-documenting code", and not with comments, then you are purposefully not using all the tools at your disposal to encode meaning as efficiently as possible.
Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Not to mention complex numerical optimization code that mixes closed-form approximations and something like Newton.
Without guides as to why a particular hairy expression is a good idea as a first estimate, the code is pretty much unreadable. (E.g. is it setting derivatives to zero, using a polynomial approximation, or something else?)
i think people took this too literally.
To put it another way, comments are for irreducible complexity ir external systems outside your control.
I work between systems and app dev. Systems have comments more often esp in shaders but my god informing me that a variable named isActive is for if something is…active, is useless noise. Same with the majority of comments that a type system already tells you. In my career, these have been ~90% of the comments I see. Since ai, all new code it is 100%.
Most of the replies examples are a sign of bad system/code but it is not always controllable. A legacy code comment of, the api requires strings for boolean values in the form “yes” and “no”. That is useful but it is also a code smell.
A concrete example, a vendor decided to define a proto with a flattened array of objects so there are some 1800 uniquely named fields on it. In many downstream consumers, this is a real performance issue besides being confusing. A comment may be good there. The thing is, this was still solvable if up at the root of where this vendor’s hardware logs data remapped it to something sane so every downstream system wouldnt need a comment explaining wtf is going on.
I see comments as when you want to explicitly answer why code smells right when a reader is smelling it.
The code tells you what the code does. It does not explain why it is doing that, and not something else. That is, among other things, what documentation does, and that includes comments.