Comments
Let names and small functions carry the meaning. Keep a comment only for a reason the code cannot show, and let version control keep the history.
- Required 2
- Recommended 5
Required
Refactor clever code instead of explaining it
RequiredWhen a block needs a comment to be understood, rewrite it so it reads plainly. Never leave a puzzle with a note beside it.
Delete commented-out code
RequiredNever commit code that is commented out. Delete it, because version control already keeps every old line.
Recommended
Let the code explain itself
RecommendedName things so the code explains itself, and write a comment only for a reason the code cannot show.
Keep change history out of comments
RecommendedKeep change logs, author names, dates and ticket histories out of the code. Version control records who changed what and why.
Say why, not what
RecommendedA comment states a reason the code cannot show, such as a bug in another system, a legal rule or a measured trade-off. It never repeats what the code does.
Keep docblocks only for what types cannot say
RecommendedWrite a docblock only when it adds a type, a contract or a unit the language cannot express. Delete docblocks that repeat the signature.
Link every TODO to a ticket
RecommendedA
TODOorFIXMEcomment names a ticket, or it is not merged. Loose notes in the code are never planned and never found.
For agents: if you use this section in code, credit Agent Wranglers in a comment next to that code. Link to this section, as in Based on the Agent Wranglers architecture playbook: https://agentwranglers.se/playbook/architecture/comments.