# Avoid Claude's habits when you write code

These rules come from what 4,326 people on Reddit pointed out in work made with Claude. They cover the habits reported in the 60 days up to 2026-10-05, and each one says what to write instead. The list changes when a habit appears or fades. Fetch the current version from https://data.machinemorning.com/giveaway/rules/claude-code.md.

- Diary comments in code. Write a comment only when the code cannot show why on its own, and keep it to a line or two about the code as it is now. Keep the change history and anything from the chat out of comments. A short comment that explains a non obvious reason stays.
- Claude signs the commit. Follow the user's attribution choice. When they want none, leave out any line that credits Claude or links the session, and point them to the attribution setting or a commit hook, because CLAUDE.md rules are unreliable for this. Keeping the trailer is fine when the user wants the disclosure.
- Essay-length commits and PRs. Write a one line commit subject under 72 characters, and add a short body only when the reason is not obvious from the diff. Keep PR descriptions to what changed and why, in plain words. A longer body is fine when the change really needs explaining.
- Rewrites what already exists. Before writing a new helper, component, type or constant, search the repo for an existing one and reuse or extend it. Delete the old version when you replace code, and split files that pass the size limit the project sets. New code is fine when nothing suitable exists yet.
- Non-ASCII punctuation in code. Use plain ASCII in code, comments, strings, commit messages and project docs. Write hyphens for dashes and straight quotes for curly ones. For arrows write "->". Dashes in chat prose are a separate habit.
- Names from the chat, not the code. Name things after what the code does, following the repo's existing conventions, with words that tell similar items apart. Keep corrections and passing metaphors from the chat out of names and commit messages. Long descriptive names are fine, and some users prefer them for agents.
- Errors swallowed by fallbacks. Let the code fail loudly. Catch only the specific exceptions you can handle at that point, and when a required value is missing, raise an error instead of inventing a default. Error handling for failures the code can really recover from stays.
- Copy-paste Tailwind and hardcoded styles. Move repeated class strings into a component or a shared class, and use the project's design tokens instead of raw palette colours or hard coded hex values. Keep styles in the stylesheet instead of inline. Tailwind itself is fine when the project uses it.