How to Write Clean Code

Clean code is code that reads like prose — a new developer can follow it without a map, and a future you can modify it without fear. Clean code isn’t about elegance contests or following every rule in a book; it’s about reducing the cognitive load for the next person to touch it, which is almost always yourself in six months.

This guide covers practical, language-agnostic principles that separate code that lasts from code that has to be rewritten. Not theory; the stuff that moves the needle in real reviews.

1. Name things precisely

Naming is the single biggest lever in readability. getUserData() is vague; fetchActiveUserProfile() is clear. Avoid abbreviations unless they’re standard in your domain. Names should reveal intent; if you need a comment to explain what a variable holds, the name is wrong.

2. Functions do one thing

Single Responsibility Principle, condensed: a function should have one reason to change. If you can’t describe a function in one short sentence without “and,” it’s doing too much. Break it up — small focused functions are easier to test, reuse, and understand.

3. Keep functions short

A function that doesn’t fit on a screen is usually hiding multiple functions. Aim for 20 lines as a rough ceiling. Exceptions exist (big switch tables, specialized algorithms), but they should feel like exceptions — not the norm.

4. Prefer clarity to cleverness

A one-line ternary that’s hard to read is worse than an 8-line if/else that’s obvious. Future-you will thank present-you for the obvious version. The industry’s best engineers write boringly clear code; it’s juniors trying to show off who write clever code.

5. Handle errors explicitly

Don’t swallow exceptions. Don’t return null to signal “something went wrong.” Either handle the error at the right level or propagate it with context. Every silent failure is a future debugging session.

6. Don’t comment what you should have named

// Loop through users and send emails above a loop that does exactly that is noise. A comment should explain why, not what. If the code needs a comment to explain what it does, extract a function with a descriptive name instead.

7. Delete dead code

Commented-out code, unused imports, abandoned helpers. Your version control already remembers the old version. Carrying dead code forever bloats files and introduces “wait, is this used?” friction during reviews. Delete it.

8. Keep the call site simple

A function taking 7 positional arguments signals a design problem. Prefer named parameter objects, sensible defaults, and splitting into smaller functions. The caller should be able to read the call and know what it’s doing without jumping to the definition.

9. Test the hard parts

You don’t need 100% coverage; you need coverage where mistakes are costly and non-obvious. Complex business logic, edge cases, parsing, anything with money. Simple glue code and trivial getters often don’t need tests — but the tricky bits absolutely do.

10. Separate pure logic from side effects

Functions that do a calculation should not also write to disk, call APIs, or mutate global state. Keep pure logic pure — it’s trivially testable. Isolate side effects at the edges of your program. This single pattern dramatically reduces bug rates.

11. Make impossible states impossible

If two flags in your state can never both be true, make that impossible in the type system rather than managing it in code. “User is logged in but has no ID” should be unrepresentable, not guarded against. Rich types prevent whole categories of bugs.

12. Write for the reader, not the compiler

Any code you write will be read 100 times for every time it’s written. Optimize for reading. Consistent formatting (use a formatter), consistent naming, consistent patterns. Predictability is worth a lot more than personal style.

Your code review checklist

Before opening a PR, review your own diff with these questions: Are the names clear? Does each function do one thing? Are errors handled? Is there dead code? Are the tests there for the hard parts? This 5-minute self-review catches most of what would otherwise come back in comments. Pair with our interview prep guide for the adjacent skill of explaining code under pressure.