Comment by Taikonerd
13 hours ago
I find that Claude Code writes very long comments, longer than even a human trying to be helpful would write.
I figure that it's basically making notes for itself, when it has to revisit the same code in a fresh session.
``` /* 2026-06-01 Dear diary, today I increased GLOBAL_WINDOW_PADDING from 8 to 16 because the user (who hurt my feelings with his crude language!) said that the app felt too crowded. */ const GLOBAL_WINDOW_PADDING = 8; ```
This drives me mad.
I like the part where the value is actually still 8
You're absolutely right. I did not increase it to 16, and it's my fault that the seam—which was right there the entire time—was not flipped towards the bucket that drips into the ocean—want me to correct this before we move onto the real story?
3 replies →
A colleague of mine has started to use Claude and he now does the longest commit messages I’ve ever read.
He doesn’t. Claude does.
> I figure that it's basically making notes for itself, when it has to revisit the same code in a fresh session.
That sounds like a great thing to do even if you are a human writing code for other humans. Most codebases out there are terrible for newcomers because of how little they explain why they are doing what they are doing, both in the code and in the often non-existent design notes.
In principle, I would agree, however, the types of comments Claude writes are sometimes absurd. It will leave a 25 line comment above a variable talking about how in a debug session, it turned out that this value was too low, so it was increased on the current date to account for whatever. It will also leave giant comments like, reference security review from 2026-05-21. Even when that document is not committed
It will also inject a tons of information that it shouldn't. I do a lot of data pipelines and comments will be like, "this line is because there's 943,048,032 events in the blah table and it forms a conjunctive set with the 43,390,042 rows of the bar table..." but doesn't include the context that was run against a dev instance.
And if I don't catch these and remove the bad information, subsequent passes will flag those comments and get stuck on the fact that numbers don't match and start digging into that "problem" instead of staying on topic.
1 reply →
these comments are not helpful and in fact hurt readability. i just delete them and would love to automatically do that honestly. cuz claude still drops long winded comments on every method even if i ask it not to
Post edit hook that reject edit based on comment density, mine is at 5% you will also need to heed deny file edit in automode as the rascal will try that to preserve prose
I'd much rather have it in the commit log than the code, though.
You may be interested in Epiq. Its is an issue tracker sourcing state from a log in state branch.
> That sounds like a great thing to do
I agree it _sounds like a great thing to do_ but the comments Claude creates make me want to never read code again. They're so obtuse and often completely pointless.
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.
2 replies →
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.