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.
pyrale 11 minutes ago [-]
> Smart developers don’t write mazes.
You don’t choose what your forebears have written, though.
jorisw 6 minutes ago [-]
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.
Tade0 4 minutes ago [-]
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.
jarofgreen 1 hours ago [-]
> 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.
someothherguyy 49 minutes ago [-]
What? You don't like horizontally scrolling 6000 columns to read something?
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.
there are also extensions for vscode that do this, vim plugins, etc
dozerly 58 minutes ago [-]
Who doesn’t have soft wrapping enabled in 2026? Line breaks are irrelevant
jarofgreen 40 minutes ago [-]
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.
ezrabuenk 44 minutes ago [-]
I, in fact, do not have wrapping enabled in my IDE....
tacomagick 39 minutes ago [-]
You never wrote Java I see
xboxnolifes 30 minutes ago [-]
Java is why I don't have line wrapping enabled. It makes code unreadable when everything needs to be wrapped.
Lindby 50 minutes ago [-]
Soft like breaks in a code editor? That's insane
Cockbrand 45 minutes ago [-]
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.
verdverm 53 minutes ago [-]
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
monster_truck 19 minutes ago [-]
Once again I am asking, who is this person and why do they think they are qualified to tell me what's best?
jdw64 18 minutes ago [-]
Sounds good. I've lost count of how many mazes I've made. Just call me the Architect of the Labyrinth.
23 hours ago [-]
Rendered at 07:16:13 GMT+0000 (Coordinated Universal Time) with Vercel.
> 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.
You don’t choose what your forebears have written, though.
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.
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.
https://en.wikipedia.org/wiki/Code_folding
there are also extensions for vscode that do this, vim plugins, etc
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.