151–160 of 200 posts
Earlier quoted context omitted.
I've come recently across arxiv 2604.20911 which claims "do" rules persist much better then "don't" rules.
Alright, what you'd put instead of "Don't add any code comments anywhere"? I agree with the general guidance, but it's a general one and not applicable for everything. Some things cannot be expressed in a "do" way rather than "don't".
For example this says > Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue.
You can bet sol is going bend over backward to reduce indentation now and write non idiomatic code
Earlier quoted context omitted.
Incidentally, I'm from the opposite school and consider every “if” followed by a braced block a smell. If a conditional body needs a block, it's doing enough to deserve a name, so I promote it to a single named call, à la "Extract till you drop".
So you’ll make a two line function to replace a braced block? Seems kind of unhinged.
The most powerful change I have run into is: "Positive phrasing" as a default, prefer to tell the model what they should do, and why. Not a prohibition on a behavior. When you say "don't do x" you are just pre-seeding the model with "x" and the prohibition mitigates that some, but not as much as never having put "x" in the context in the first place. "Do Y, for these reasons" can be shaped to achieve what you mean by…
Earlier quoted context omitted.
I forbid my agents from adding any comments. I review the code and add comments manually. If I can't understand something despite having the context then I throw away the code instead of having an LLM generate comments to explain what it did. This way the code stays readable/debuggable by humans.
> This way the code stays readable/debuggable by humans. Please take the following as expressed with genuine curiosity: Do you not use an editor with syntax highlighting and collapsible comments? At least on JetBrains you can configure the editor to collapse all comments on open and to have the comments displayed in a low-contrast color. This way, LLMs add a bunch of comments, but it doesn't affect your actual experi…
The next developer doing a review will see it. The next agent iteration will see it.
If the comment is wrong (even slightly) or redundant, that will help noone.
A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
> Propose ASCII drawings to explain complete systems. LLMs are very bad at ASCII drawings. https://medium.com/data-science/why-llms-suck-at-ascii-art-a...
Labs have now long understood that ASCII drawing is a core skill needed for coding agents. However, I would not trust them understanding what an existing drawing means, unless it has generated itself.
A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
Earlier quoted context omitted.
I think “This way the code stays readable/debuggable by humans” is a proof by example (not that the generated comments are necessarily bad). If the human can read/understand it well enough to comment it, then it is readable by humans.
> If the human can read/understand it well enough to comment it, then it is readable by humans. No, because the one who is writing the comment has context later reader dont. The writer knows what the requirements are, what he was trying to achieve and what he struggled to comprehend. Writer also presumably spent more time trying to understand it then the person coming later should.
Besides, it has always been like this. I sometimes can't even understand some of the things I wrote myself a couple of months ago, because I forgot the context. Good comments and documentation will help you re-acquire the context you need, not completely eliminate it.
Earlier quoted context omitted.
Alright, what you'd put instead of "Don't add any code comments anywhere"? I agree with the general guidance, but it's a general one and not applicable for everything. Some things cannot be expressed in a "do" way rather than "don't".
I don't know. I fully agree, and never did really try out this in depth yet. I suspect rules with negations are not the same as don't rules, but unknown if really true, if so: "when writing code do not add comments, code should not need it" may work
I use things like "Your code should be self-documenting, so as to require as few comments as possible. Add comments to explain "why" or give important context not apparent from the code itself, but keep them to necessary comments only"
But that's a much laxer rule. I don't think you can truly express "no comments, ever" without a "don't" rule.
I'm not necessarily looking for the latest and greatest - more papers that those in the community have coalesced around providing nice ways of summarising problems or as a good example of a specific area.