Roast My Code

Why it matters

Everyone writes code that works. Great engineers write code the next person can understand, change, and run without fear. Code review exists because bugs hide in readability — in ambiguous names, tangled control flow, and functions that do three jobs at once. A second pair of eyes, even an automated one, catches what the author is blind to.

This roast reads your snippet the way a sharp reviewer would. The brutal roast finds the crimes against readability. The code audit checks structure, naming, duplication, and error handling. The performance pass flags the obvious inefficiencies. And the friendly review gives you the refactoring direction without the ego. Paste any language — the critique adapts.

Common mistakes

• Variable names that describe nothing. `x`, `data`, `temp`, and `result` force the reader to hold the whole function in their head. Names should carry the meaning.
• Functions that do three jobs. A function that validates, transforms, and writes is a bug farm. One function, one job, one name.
• Deep nesting and early returns ignored. Four levels of indentation hide logic errors. Early returns and guard clauses flatten the code and surface the happy path.
• Swallowed errors. `catch {}` with no log, no rethrow, no context. Swallowed errors are how production bugs go undiagnosed for months.
• Duplicated logic copied instead of abstracted. Copy-paste works twice and fails the third time. Duplication is a maintenance tax on every future change.
• Magic numbers and string literals. `if (code === 403)` and `timeout = 5000` — the reader has no idea what 403 or 5000 mean without a comment or a constant.

The checklist

• Names describe intent, not type. `usersPendingReview` over `list2` — always.
• Small functions with one responsibility. If you need a comment to explain what a function does, split it.
• Error paths handled explicitly. Every catch should log, return a sane default, or rethrow with context.
• No dead code or commented-out blocks. Version control remembers — delete the graveyard.
• Consistent style. Formatting that matches the file around it, even when you disagree with it.
• Bounded loops and safe recursion. Anything that could run forever needs an exit condition and a guard.
• No secrets or credentials in code. Keys in configs and envs, never in source.
• Tests exist for the tricky paths. If it was hard to write, it needs a test to keep it working.
• Dependencies justified. A 10-line utility is cheaper than a new dependency with a supply chain.
• Obvious performance traps avoided. Nested loops over data you could index, work repeated on every render.

How to use Code

1. Paste a focused snippet. One function or module beats 500 lines of a whole app — the critique stays sharp.
2. Name the language and context. Frontend, backend, or script; framework or vanilla — context sharpens the review.
3. Run the audit pass. Get the structural read first: names, nesting, duplication, error handling.
4. Apply the top fixes. Rename, extract, flatten — the cheap refactors that compound.
5. Re-run after refactoring. Confirm the refactor did not introduce a new smell.

What this roast checks

Code reviews usually come from teammates who are too polite — or too busy — to say what is actually wrong. The roast reviews your code the way a sharp senior engineer would. The savage persona flags the smells people notice but rarely bother to write down: dead code, copy-paste duplication, functions doing too much, and names that lie. The maintainability pass checks structure, error handling, and whether the next developer to touch this code will understand it without a briefing. The result is a practical, prioritized list of what to change and why.

5 pro tips from the review

• Fix the names first. A name that lies costs you hours of reading time later — rename before you refactor.
• Extract anything duplicated more than twice. Copy-paste is how bugs multiply silently.
• Keep functions to one responsibility. “Does two things” is the most common failure mode in readable code.
• Handle the error paths before the happy path. The unchecked edge cases are where production breaks.
• Delete dead code and unused imports. Every line you keep is a line someone will read, and possibly trust.

By the numbers

Related guides

• Clean Code Principles
• Git Commit Message Best Practices
• Get Better Feedback on Creative Work

Roast a famous website

• Roast GitHub's Website
• Roast Cloudflare's Website
• Roast Sentry's Website