# Avoid ChatGPT's habits when you write code

These rules come from what 4,059 people on Reddit pointed out in work made with ChatGPT. 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/chatgpt-code.md.

- Narrating, jargon-heavy comments. Write comments that explain what the code does or why in plain words, and leave out notes about what was just changed or what the user asked for. Do not reword existing comments that the task does not touch. Short comments that explain why a line exists stay welcome.
- Thin, tidy commits. Follow the repository's commit style and every commit rule you were given, letter case included. Add a body that says what changed and why when the change is more than trivial, and keep the README written for users without working notes.
- Fallbacks everywhere. Read a value under the one name it has and let a missing or null value raise a clear error, unless the user asks for graceful handling. Remove old names and compatibility paths in new code instead of keeping them beside the new ones, and never fill missing data with placeholders or zeros. Defensive handling stays fine in production code where the user wants it.
- Layered names, unasked renames. Name things after what they do in the domain and add a Runtime, Worker, Registry or Store layer only when it has its own job. Leave existing names and comments outside the task as they are, and follow the naming already in the repo. Clean names that document themselves stay fine.
- Em dashes around the code. In READMEs and code comments, join clauses with a comma or a full stop where a "—" would go. Rewrite the sentence when you remove a dash instead of swapping in " -- ". That covers "--". Triple quoted docstrings are normal Python and stay fine.
- Clean code, hidden holes. Use only parameters you can confirm in the installed version of a library, and say so when you are unsure of an API that changes often. Make a failed auth check stop the request and read secrets from the environment instead of source files.
- Duplicates instead of reusing. Search the codebase for an existing helper before writing a new one and move repeated code into one shared function. Replace the old parameter or method when you add a new one, and split very large files by concern.
