I don't know if I'm doing something wrong, but every time I ask gemini 2.5 for code it outputs SO MANY comments. An exaggerated amount of comments. Sections comments, step comments, block comments, inline comments, all the gang.
```python
def whatever():
--- SECTION ONE OF THE CODE ---
...
--- SECTION TWO OF THE CODE ---
try:
[some "dangerous" code]
except Exception as e:
logging.error(f"Failed to save files to {output_path}: {e}")
# Decide whether to raise the error or just warn
# raise IOError(f"Failed to save files to {output_path}: {e}")(it adds commented out code like that all the time, "just in case")
It's terrible.
I'm back to Claude Code.
In any case, it knows what good code looks like. You can say "take this code and remove spurious comments and prefer narrow exception handling over catch-all", and it'll do just fine (in a way it wouldn't do just fine if your prompt told it to write it that way the first time, writing new code and editing existing code are different tasks).
Just end your prompt with "no code comments"
Claude 3.7 Sonnet is much more restrained and does smaller changes.
I’ve started in a narrow niche of python/flask webapps and constrained to that stack for now, but if you’re interested I’ve just opened it for signups: https://codeplusequalsai.com
Would love feedback! Especially if you see promising results in not getting huge refactors out of small change requests!
(Edit: I also blogged about how the AST idea works in case you're just that curious: https://codeplusequalsai.com/static/blog/prompting_llms_to_m...)
simonw has symbex which could be useful for you for python
Or something similar that does not rely on negation.
I also try and get it to channel that energy into the doc strings, so it isn't buried in the source.
Besides, other models seems to handle negation correctly, not sure why it's so difficult for the Gemini family of models to understand.
Refractor this. Do not write any comments.
<code to refractor>
As a reminder your task is to refractor the above code and do not write any comments.
Literally both of those are negations.
If you think negations never work tell Gemini 2.5 to "write 10 sentences that do not include the word the" and see what happens.
If it is ingesting data, there should also be a sample of the data in a comment.
"5. You must never output any comments about the progress or type of changes of your refactoring or generation. Example: you must NOT add comments like: 'Added dependency' or 'Changed to new style' or worst of all 'Keeping existing implementation'."
But I've heard "defensive code" used for the kind of code where almost every method validates its input parameters, wraps everything in a try-catch, returns nonsensical default values in failure scenarios, etc. This is a complete waste because the caller won't know what to do with the failed validations or thrown errors, and it's just unnecessary bloat that obfuscates the business logic. Validation, error handling and so on should be done in specific parts of the codebase (bonus points if you can encode the successful validation or the presence/absence of errors in the type system).
lots of hasattr("") rubbish, I've increased the amount of prompting but it still does this - basically it defers it's lack of compile time knowledge to runtime 'let's hope for the best, and see what happens!'
Trying to teach it FAIL FAST is an uphill struggle.
Oh and yes, returning mock objects if something goes wrong is a favourite.
It truly is an Idiot Savant - but still amazingly productive.
x = 1 // set X to 1
You get:
x = 1 // added this to set x to 1
And sometimes:
// x = 1 // removed this
These comments age really fast. They should be in a git commit not a comment.
As somebody who prefers code to self-describe what it is doing I find this behaviour a bit frustrating and I can't seem to context-prompt it away.
Removed from where? I use the attach code folder feature every day from the Gemini web app (with a script that clones a local repo that deletes .git and anything matching a gitignore pattern).
Which means if you try to force it to stop, the code quality will drop.
Models use comments to think, asking to remove will affect code quality.
I don't have problems with getting lot's of comments in the output, I am just deleting it while reading what it did
What does that mean?
"Sometimes the big fish isn't only the fish"