Comments in code are instant technical debt. They need to be maintained alongside the code, so you are *programming" twice. Avoid comments, except when they really explain some obscure, incomprehensible section of code or to prevent explorers from the future getting smacked on the face twice by the same stick. I find myself using the latter often to tell future agents what not to do in the next few lines.

Comments are absolutely important. Your code answers ‘what’ but not why. Comments are for the why.

You need to use comments, when your code doesn't make sense to the reader. A way better approach is to write code which makes sense to readers. There are cases when you need to write incomprehensible code for the sake of performance, for example, but that's rare. Even in high performance environments. Or maybe you need one for some bugfixing. But most of the strange "bugfixing", or performance "improvements" what I saw in my life was just technical debt, and coders were lazy, or had time pressure. It's really very rare when you really should use a comment. When I think about writing a comment, I immediately think through, or look into more whether there is a better approach. Usually, you can use Git, or Git+ticketing systems anyway for business reasons.

So far Clause Code's comments on my code were completely useless. They just repeated what you could figure out from the name of called functions anyway.

Edit: an obvious exception is public libraries to document public interfaces, and use something like JavaDoc, or docstrings, etc.

Most Claude Code comments answer the "what", or worse they answer the why in a way that makes no sense outside the context of that session. Stuff like adding a comment saying why they removed our changed code that they'd just written

Thoughtful comments can provide the why, but they can just as easily be a redundant re-statement of the what in the code, which llm comments quite often are.

Comments describing the program are a form of error correcting code. Redundancy vs efficiency yadda yadda, just make an informed decision instead of a half baked belief; programming more than once is the point, necessarily. (And I don’t mean ‘// add 2 to x’ comments, these are properly useless, I agree - unless they say why x needs to have 2 added.)

I bet you that if you let it comment code, it would produce better code as it acts like an inline rubber-duck basically

I recall a study that said AI coded much better when in codebases with dense commenting.

I'm wondering if tsdoc/jsdoc tags like @link would help even more for context

This is why, when you do have comments, they should generally be in the DocBlock and discuss the code in domain-problem terms.

imo, comments are quite good for junior developers. docstrings are much preferred though.

Avoiding comments is an exercise in thinking how to rename or refactor a function, or a variable in such a way that a junior developer will be able to read it like prose, and immediately understand what's going on.

It's cognitively stressing, but is beneficial for juniors, and developers new to the codebase, just as it is for senior developers to reduce the mental overhead for the reader.

It's always good to spend an extra minute thinking how to avoid a comment.

Of course there are exceptions, but the mental exercise trying to avoid having that exception is always worth it.

Comments are instant technical debt.

Especially junior developers will be extremely confused and slowed down by having to read both, the comment, and then the code, which was refactored in the meantime and does the opposite of what the comment said.

This is awfully purist.

I think a happy medium of "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment" would be good.

I don't know where this "comments are instant technical debt" meme came from, because it's frankly fucking stupid, especially in the age of being able to ask the LLM "please find any out-of-date comments in this code and update them" since even the AI-averse would probably not object to it commenting code more correctly than the human did

Not commenting code seems like the most unhinged thing I can think of. We don't need blueprints to build this building gestures broadly isn't it obvious to the construction workers where to put everything?

The blueprint is the code.

I don't know, I tend to agree. I feel like the number of times I've been thrown off by an out of date comment for code that could have probably been refactored to be clearer, outweigh the times a comment has helped.

Docstring comments are even worse, because it's so easy for someone to update the function and not the docstring, and it's very easy to miss in PR review

As always the problem isn't the actual thing being discussed - the problem is shitty developers who wrote shitty comments and/or don't update comments when they update code.

Good and up to date comments are good and up to date. Bad and outdated comments are bad and outdated. If you let your codebase rot then it rots. If you don't then it doesn't. It's not the comment's fault you didnt update it. It's yours.

It's always a skill issue.

Guard rails should be there to prevent inexperienced developers (or overworked, tired ones) from committing bad code.

"Try to think how to refactor functions into smaller ones and give them meaningful names so that everyone knows immediately what's going on" is a good enough guard rail.

> "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment"

That's exactly what I wrote, phrased slightly differently.

We both agree at the core.