[kelnos]

> IMPORTANT: DO NOT ADD *ANY** COMMENTS unless asked*

Interesting. This was in the old 1.x prompt, removed for 2.0. But CC would pretty much always add comments in 1.x, something I would never request, and would often have to tell it to stop doing (and it would still do it sometimes even after being told to stop).

[epiccoleman]

I can't decide if I like this change or not, tbh. I almost always delete the comments Claude adds, to be sure - but at the same time they seem to provide a sort of utility for me as I read through the generated code. They also act, in a funny way, as a kind of checklist as I review changes - I want them all cleaned up (or maybe edited and left in place) before I PR.

[moozilla]

I like to think of models leaving "useless comments" as a way to externalize their reasoning process - maybe they are useless at the end, but leaving them in on a feature branch seems to marginally improve future work (even across conversations). I currently leave them in and either manually clean them up myself before putting up a PR for my team to review or run a final step with some instructions like "review the diff, remove any useless comments". Funnily enough Claude seems pretty competent at identifying and cleaning up useless comments after the fact, which I feel like sort of proves my hypothesis.

I've considered just leaving the comments in, considering maybe they provide some value to future LLMs working in the codebase, but the extra human overhead in dealing with them doesn't seem worth it.

[resonious]

I've been wondering if the "you're absolutely right!" thing is also similar. Like maybe it helps align Claude with the user or something, less likely to stray off or outright refuse a task.

[syspec]

Wouldn't it stand to reason that they would provide a sort of utility for a collegue as they read through the generated code.

[robertfw]

comments for me are a code smell:

- like all documentation, they are prone to code rot (going out of date)

- ideally code should be obvious; if you need a comment to explain it, perhaps it's not as simple as it could be, or perhaps we're doing something hacky that we shouldn't

[sophiabits]

Comments are often the best tool for explaining why a bit of code is formulated how it is, or explaining why a more obvious alternate implementation is a dead end.

An example of this: assume you live in a world where the formula for the circumference of a circle has not been derived. You end up deriving the formula yourself and write a function which returns 2piradius. This is as simple as it gets, not hacky at all, and you would /definitely/ want to include a comment explaining how you arrived at your weird and arbitrary-looking "3.1415" constant.

[stefan_]

Meanwhile they deleted the "do not add emojis" part. Look forward to all sorts of logging messages with emojis in them.

[data-ottawa]

I don’t understand where the AI love of emojis comes from. I’ve never seen them in a professional codebase outside of basic logging.

I assume it comes from the myriad tutorial content on medium or something.

gpt-oss is the most egregious emoji user: it uses emoji for numbers in section headings in code, which was clearly a stylistic choice finetuned into the model and it fights you on removing them.

I’ve noticed Claude likes to add them to log messages and prints and with 4.5 seems to have ramped up their use in chat.

[stefan_]

It's bizarre because its not so long ago that trying to print an emoji would just mess up your terminal, if your compiler didn't already choke on it.

[marckrn]

I'm pretty sure it's caused by RLHF :wink:

[IgorPartola]

I am guessing this is an attempt to save computing resources/tokens?

[ojosilva]

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.

[ra]

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

[ruszki]

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.

[ascorbic]

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

[MaxfordAndSons]

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.

[baq]

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.)

[pmarreck]

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

[typpilol]

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

[Exoristos]

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

[navvyeanand]

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

[purerandomness]

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.

[pmarreck]

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

[ragequittah]

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?

[robertfw]

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

[purerandomness]

> "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.