Patching that up by using comments as a 'map' isn't the right way to deal with that. Refactors and rearchitecture are. Putting in comments just helps procrastinate what's necessary.
Rewrites require a lot of effort, significantly more than just adding comments. It’s a pragmatic tool until you actually have the time to do the rewrite.
I'm afraid this all gets thrown out the window nowadays.
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I ask them to write comments in ASD-STE100 Simplified Technical English, but all I really get from that is tersness.
Also the other day I stumbled upon a huge pile of documentation and I'm still trying to figure out if it's human or machine written. I stopped reading it half way through as I figured that perhaps it wasn't written for humans to read.
The most WTF comments are the ones that describe how the code looked during a rewrite session with no commits. He writes bad code, I ask him to rewrite it, and he leaves a comment saying why the previous implementation was bad, with no history in git of the previous implementation.
> Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
Well, my LLMs are "smarter" than yours. They'll describe why the code is there. They'll even try to keep these comments in sync with code as it makes changes.
This includes describing the "why" behind the change even on code affected only accidentally, e.g. by reformat or reindent. And, if it wrote some code and then later learned half of it is wrong, it'll remove the offending parts and leave comments telling what used to be there, and why it isn't anymore.
Same for commit/PR messages.
May or may not be related to a recent tendency in Opus/Fable models I noticed, to eagerly turn user feedback into rules, self-correct by adding more rules, and then when some rule fails, correct it by adding a counter-steering rule - accumulating rules until eventually getting lost in them.
> Typically keep comments on a single line without line breaks — if a comment is useful, developers will scroll to read them, if it’s not they can easily scroll past it.
Disagree. Personally that sounds like a massive barrier to reading the comment to me. Limited width column text is generally regarded as easier to read, make your comments easier to read. Especially as I probably have the code open in a limited width window, as that's what I expect from code.
Yeah, if IDE's allowed code folding of comments then the authors original problem (having to scroll past comments they thought weren't useful) wouldn't be that big a deal.
If line breaks really were irrelevant, the author wouldn't have felt the need to give a tip all around optimising line breaks.
Personally, I would have hoped by 2026 we had better IDE's and tools for managing code in text files such that developers with different preferences for a number of characters in a column or things like how you display comments can be accommodated. Yet still teams end up arguing about what standard to use.
This is a bit like vim vs Emacs - everyone should be able to use their favorite setup, and the formatting should not get in the way of the engineer's preferences.
Who makes assumptions about how others do things in 2026? Line breaks are apparently relevant, review agents complain about them, soft breaks are super annoying for vim motion users, opinions are still like ani
I disagree with the overall sentiment of this article. I wouldn't say comments are never useful, because they certainly can be. But once verbose commenting becomes the norm, people (and now especially LLMs) will overuse them, making the code unnecessarily obtuse and difficult to read. And the point about maintenance is real.
There are also a couple of 'pointless' statements in the article itself:
> "Use a combination of in-line and standalone comments, depending on the situation"
When code is a maze describes my 1988 IOCCC entry [1]
[1] https://tromp.github.io/pearls.html#mazeVery cool, thanks for sharing!
If, like me, you're trying to compile it, don't forget to set the
flag in gcc, so: Then run it as:Smart developers don’t write mazes.
> In code, comments are our signposts
No. Naming and good architecture are. Intuitive folder trees. Concise docs. Clear separation of concerns such that naming can suffice.
The more comments you need to ‘map’ your code, the worse of a job you’ve done.
> Smart developers don’t write mazes.
You don’t choose what your forebears have written, though.
Patching that up by using comments as a 'map' isn't the right way to deal with that. Refactors and rearchitecture are. Putting in comments just helps procrastinate what's necessary.
Rewrites require a lot of effort, significantly more than just adding comments. It’s a pragmatic tool until you actually have the time to do the rewrite.
I'm afraid this all gets thrown out the window nowadays.
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I ask them to write comments in ASD-STE100 Simplified Technical English, but all I really get from that is tersness.
Also the other day I stumbled upon a huge pile of documentation and I'm still trying to figure out if it's human or machine written. I stopped reading it half way through as I figured that perhaps it wasn't written for humans to read.
The most WTF comments are the ones that describe how the code looked during a rewrite session with no commits. He writes bad code, I ask him to rewrite it, and he leaves a comment saying why the previous implementation was bad, with no history in git of the previous implementation.
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I wonder if that's actually useful for an LLM though. It's additional context that should steer the LLM not to change the code to do something else.
> Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
Well, my LLMs are "smarter" than yours. They'll describe why the code is there. They'll even try to keep these comments in sync with code as it makes changes.
This includes describing the "why" behind the change even on code affected only accidentally, e.g. by reformat or reindent. And, if it wrote some code and then later learned half of it is wrong, it'll remove the offending parts and leave comments telling what used to be there, and why it isn't anymore.
Same for commit/PR messages.
May or may not be related to a recent tendency in Opus/Fable models I noticed, to eagerly turn user feedback into rules, self-correct by adding more rules, and then when some rule fails, correct it by adding a counter-steering rule - accumulating rules until eventually getting lost in them.
> Typically keep comments on a single line without line breaks — if a comment is useful, developers will scroll to read them, if it’s not they can easily scroll past it.
Disagree. Personally that sounds like a massive barrier to reading the comment to me. Limited width column text is generally regarded as easier to read, make your comments easier to read. Especially as I probably have the code open in a limited width window, as that's what I expect from code.
What? You don't like horizontally scrolling 6000 columns to read something?
https://en.wikipedia.org/wiki/Code_folding
Yeah, if IDE's allowed code folding of comments then the authors original problem (having to scroll past comments they thought weren't useful) wouldn't be that big a deal.
many do. for example: https://www.jetbrains.com/help/idea/code-folding-settings.ht...
there are also extensions for vscode that do this, vim plugins, etc
Who doesn’t have soft wrapping enabled in 2026? Line breaks are irrelevant
If line breaks really were irrelevant, the author wouldn't have felt the need to give a tip all around optimising line breaks.
Personally, I would have hoped by 2026 we had better IDE's and tools for managing code in text files such that developers with different preferences for a number of characters in a column or things like how you display comments can be accommodated. Yet still teams end up arguing about what standard to use.
I, in fact, do not have wrapping enabled in my IDE....
You never wrote Java I see
Java is why I don't have line wrapping enabled. It makes code unreadable when everything needs to be wrapped.
Soft like breaks in a code editor? That's insane
And so the war began.
This is a bit like vim vs Emacs - everyone should be able to use their favorite setup, and the formatting should not get in the way of the engineer's preferences.
Who makes assumptions about how others do things in 2026? Line breaks are apparently relevant, review agents complain about them, soft breaks are super annoying for vim motion users, opinions are still like ani
I disagree with the overall sentiment of this article. I wouldn't say comments are never useful, because they certainly can be. But once verbose commenting becomes the norm, people (and now especially LLMs) will overuse them, making the code unnecessarily obtuse and difficult to read. And the point about maintenance is real.
There are also a couple of 'pointless' statements in the article itself:
> "Use a combination of in-line and standalone comments, depending on the situation"
isn't that just every kind of comment?
Once again I am asking, who is this person and why do they think they are qualified to tell me what's best?
Sounds good. I've lost count of how many mazes I've made. Just call me the Architect of the Labyrinth.