Clean Code Principles for Beginners [2026]

The clean code principles that hold up, the ones that are contested, and real before and after examples. Written for beginners, honest about the arguments.

Per Harald Borgen

Per Harald Borgen

— 11 min read
Clean Code Principles for Beginners [2026]

Clean code is code the next person can read and change safely, which is a different goal from code that satisfies a checklist. The habits that pay off fastest are precise names, functions that do one thing, no unexplained numbers, and comments that explain why rather than what. Some of the most repeated rules here are genuinely disputed by working engineers, and this guide marks those instead of pretending the field agrees.

What Is Clean Code?

Clean code is code that a competent developer who has never seen it can read, understand, and modify without breaking something they did not know existed.

The practical argument for it is that you read code far more often than you write it. Robert C. Martin, whose 2008 book Clean Code defined the vocabulary most teams still use, put that ratio at well over ten to one. He offered no study behind the number, which is worth noticing early: a lot of clean code advice is experience presented as law.

Martin was direct about that when defending his most famous rule, writing that small functions are what four decades of practice taught him rather than something he could prove.

"This is not an assertion that I can justify."

The line comes from the joint discussion he held with John Ousterhout between September 2024 and February 2025, where the two authors worked through their disagreements in public. For a beginner trying to sort settled advice from folklore, it is the most useful thing to read.

Where the main ideas actually stand:

Principle Status What actually matters
Names should reveal intent Settled The cheapest, highest-return habit in programming
A function should do one thing Settled in spirit "One thing" is a judgment call, not a line count
Functions should be two to four lines Contested Over-decomposition has its own readability cost
Comments are a failure of naming Contested Some information cannot live in code at all
Never repeat yourself Contested Early abstraction can be worse than duplication
Formatting should be consistent Settled, and automated A tool owns this now, not your opinion

Why Is Naming the Most Important Skill?

Naming is the highest-leverage clean code skill because a precise name removes the need for a comment, a lookup, and often an entire explanation.

Beginners gain more here than anywhere else. Consider a function nobody can read:

function calc(d, u) {
  const r = [];
  for (const x of u) {
    if (x.l < d) r.push(x);
  }
  return r;
}

Nothing here is broken. It is unreadable, and every future change starts with reverse engineering. The same logic, with names that carry meaning:

function findInactiveUsers(cutoffDate, users) {
  return users.filter((user) => user.lastLoginAt < cutoffDate);
}

The rules worth internalizing are short:

  • Say what it is, not what type it is. userList adds nothing that users did not already say.
  • Booleans should read as a claim. isActive, hasUnpaidInvoice, canPlaceOrder.
  • Use one verb per operation across the codebase. If you fetch in one module, do not get and retrieve in the next two.
  • Make names pronounceable and searchable. You cannot grep for d, and you cannot discuss genymdhms in a standup.

Names have a hard limit. A name says what a value is, never why it was chosen, which is where comments earn their place later in this guide.

How Small Should a Function Be?

A function should be small enough that its name fully describes what it does, and no smaller. Line counts are a symptom, not the target.

Three parts of the standard advice hold up. Functions should do one thing at one level of abstraction. Parameter lists should be short, because every extra parameter multiplies the ways a call site can be wrong. And boolean flag arguments should be avoided, because the call site stops explaining itself:

// The call site tells you nothing
renderPage(pageData, true);

Two named functions beat one function with a switch inside it:

renderTestPage(pageData);
renderSuitePage(pageData);

Now the contested part, stated plainly. In Clean Code, Martin argues functions should hardly ever reach twenty lines, describes an ideal of just two, three, or four lines, says blocks inside if and while statements should be one line long, and calls zero the ideal number of arguments. Those are not summaries invented by critics: they are the positions Martin restates in his discussion with Ousterhout.

Ousterhout's counter-argument is that decomposing this aggressively produces shallow methods: each one is trivial, but understanding any real behavior means jumping between a dozen of them, and the pieces end up entangled rather than separated. Martin conceded in the same document that code can be over-decomposed, while arguing that erring toward small pieces is safer because they can always be inlined again.

The essay that moved this argument into the mainstream was qntm's 2020 piece on why he stopped recommending the book. His central point is not that the advice sounds wrong, it is that the worked examples in the book, including a prime number generator built from methods with names like set2AsFirstPrime, are the strongest available evidence against the rule. Casey Muratori attacked a different pair of rules in 2023, dropping the ban on switch statements and the ban on knowing an object's internals, and measured his version running roughly fifteen times faster on the same workload. He was clear that performance was the frame of his course rather than a verdict on the whole book.

The usable version of the rule: extract a function when the extracted name makes the call site clearer than the code it replaces. Do not extract to hit a line count.

The same function before and after cleanup. The magic number 18 becomes a named constant, check becomes canPurchaseAlcohol so the call site reads as a sentence, and the redundant if-return-true wrapper disappears because the condition already is the answer.

What Is a Magic Number?

A magic number is an unexplained literal value in code, such as 0.0825 or 86400000, whose meaning exists only in the head of whoever typed it.

The problem is not the number. It is that when the tax rate changes, you have to find every copy and decide, one by one, whether each 0.0825 is the same 0.0825.

if (order.total > 100) {
  applyDiscount(order, 0.15);
}
setTimeout(retryPayment, 86400000);

Named constants make the intent testable and the change a single edit:

const FREE_SHIPPING_THRESHOLD_USD = 100;
const LOYALTY_DISCOUNT_RATE = 0.15;
const ONE_DAY_IN_MS = 24 * 60 * 60 * 1000;

Not every literal needs this treatment. array[0], i + 1, and count === 2 are not magic. A number earns a name when it encodes a decision somebody made, not when it is arithmetic.

Are Comments Bad?

Most comments are a symptom of a name that failed, but a specific minority carry information that code cannot express, and those are worth writing carefully.

Start with the ones to delete. This comment exists because the condition is unreadable:

// check if the user is allowed to order
if (u.age > 17 && u.verified && !u.banned && u.balance >= 0) {

Encapsulating the conditional removes the comment and gives the rule a name you can reuse and test:

if (canPlaceOrder(user)) {

Commented-out code goes the same way. Version control already remembers it, and if deleting it feels risky, the fix is getting more confident with Git and GitHub rather than keeping a graveyard in the file.

Then there are the comments to keep:

  1. Why, not what. The reason a strange decision was made, ideally with a ticket reference.
  2. Non-obvious constraints. External behavior you had to match, a rate limit, an ordering requirement.
  3. Warnings about consequences. "Changing this breaks the nightly export."
  4. Legal headers and licenses, which are not negotiable.
// Stripe rounds half up, so we do too. Matching their rounding keeps
// our invoice totals identical to theirs on every line. See PAY-4193.
const cents = Math.round(amount * 100);

Martin's position is that comments are always failures, written to compensate for an inability to express something in code. Ousterhout's is that comments carry abstraction and context code structurally cannot hold, and that missing comments cost teams far more than occasionally stale ones do. Both agreed in their joint document that some important information cannot live in code at all. Take that agreement as the rule: if the information is about the code, name it better; if it is about the world outside the code, write it down.

Who Should Own Formatting?

A formatter should own formatting, a linter should own rules, and a human should only own the decisions neither tool can make.

Formatting arguments used to eat real review time, and the tooling ecosystem has deliberately ended them. ESLint deprecated 77 formatting rules in v8.53.0 in 2023 and now points users at dedicated formatters or the community-maintained stylistic plugin, on the reasoning that maintaining everyone's style preferences was an unsustainable burden with little payoff. Prettier says outright that the main reason to adopt it is to stop the debates, which is why it will not keep adding options.

The current landscape, verified in August 2026:

Tool Owns Notes
Prettier Formatting Deliberately opinionated, option set frozen
ESLint Rules and correctness v10 is the current major since February 2026
Biome Both, one binary Claims 97% Prettier compatibility
Ruff Python, both Near-identical output to Black on Black-formatted code
You Names, structure, abstractions The part no tool decides

Set this up on day one. A formatter on save plus a linter in continuous integration removes a whole category of review comments, and it is the first thing to add to your own projects.

How Do You Reduce Nesting?

Return early. Handle the failure cases first, then let the main logic sit unindented at the bottom of the function where it is easy to find.

Deep nesting forces you to hold every open condition in your head at once:

function getShippingCost(order) {
  if (order) {
    if (order.items.length > 0) {
      if (order.country === "US") {
        return order.total > 100 ? 0 : 9.99;
      } else {
        return 24.99;
      }
    }
  }
  return null;
}

Guard clauses flatten it:

function getShippingCost(order) {
  if (!order) return null;
  if (order.items.length === 0) return null;
  if (order.country !== "US") return INTERNATIONAL_SHIPPING_USD;
  return order.total > FREE_SHIPPING_THRESHOLD_USD ? 0 : DOMESTIC_SHIPPING_USD;
}

This rule has a limit too. Guard clauses work because the function is short and the exits sit at the top. Scatter eight returns through a hundred-line function and you have traded one readability problem for another.

Where Does DRY Go Wrong?

Do not repeat yourself is sound advice applied late and dangerous advice applied early, because the wrong abstraction is more expensive than the duplication it replaced.

The failure mode is predictable. Two pieces of code look similar, someone extracts a shared helper, and then requirements diverge. Each new case gets a parameter and a conditional until the helper looks like this:

formatUserRow(user, { compact, showEmail, isAdminView, locale, forExport });

Nobody can change that helper safely now: it serves five callers with different needs. Sandi Metz named this pattern in The Wrong Abstraction and gave the fix: inline the abstraction back into every caller, then re-extract once you can see what the real shared behavior is. Dan Abramov reached the same conclusion from the other direction in Goodbye, Clean Code, describing a refactor that traded the team's ability to change requirements for less duplication, and calling it a bad trade.

A workable rule for beginners: duplicate until the third occurrence, and extract only when the copies have changed together, for the same reason, at least once. Similar-looking code is not the same as code with a shared purpose.

Does Clean Code Still Matter When AI Writes It?

It matters more, because generated code is fluent, conventional, and locally plausible, which is exactly the profile that hides the problems these principles were built to catch.

The measurable trend is not encouraging. GitClear's January 2026 analysis of 623 million changes found duplicated code blocks rose from 40.3 per million changed lines in 2023 to 73.0 so far in 2026, while moved code, the signature of real refactoring, fell from 21% of changed lines in 2022 to 3.8%. Developers are copying instead of consolidating, and assistants make copying frictionless.

Reviewing generated code for these qualities is becoming the more valuable half of the job. A practical pass, in the order of this guide:

  • Names that describe the prompt, not the domain. processData and handleRequest are what a model writes when it does not know your business.
  • A helper that already exists. This is where the duplication enters. A model cannot see the utility file two directories over, so it writes a fresh version of something your codebase already has, and neither copy gets maintained.
  • Unnamed literals. Timeouts, limits, and thresholds nobody decided on.
  • Comments that restate the code. A model will happily write // increment the counter above counter++.
  • Abstractions invented for one caller. An interface with a single implementation is a guess about a future that has not happened.

Using an AI coding assistant is fine. Reading its output critically is a skill you build the same way you built JavaScript fluency: by reading a lot of code and asking what would break.

Where Can You Learn Clean Code Properly?

Scrimba's Introduction to Clean Code, a 64-minute course taught by Dylan C. Israel, covers most of this guide in the editor rather than on the page: naming, magic numbers, function design and parameter limits, encapsulating conditionals, replacing bad comments through refactoring and Git, an introduction to linters, and code organization.

Two things to know before you start. The examples are JavaScript, so the syntax transfers to other languages but the idioms do not always. And it stays inside the fundamentals: design patterns, software architecture, unit testing, and refactoring large legacy codebases are all outside its scope. It is a Pro course, and Pro is $24.50/mo on the annual plan ($294/year), with regional, student, and promotional discounts available. Free courses on the platform include completion certificates.

Frequently Asked Questions

What is clean code in simple terms?

Clean code is code another developer can read, understand, and safely change without needing you to explain it. In practice that means precise names, small focused functions, no unexplained numbers, consistent formatting, and comments that explain why a decision was made rather than what the code does.

Is Robert Martin's Clean Code still worth reading in 2026?

It is worth knowing rather than following. The book defined the vocabulary teams still use, and its chapters on naming and side effects hold up. Its worked examples and its most specific rules, particularly on function length, are widely criticized today. Read it alongside the counter-arguments, not alone.

How short should a function be?

Short enough that its name describes everything it does. Two-to-four-line targets come from Clean Code and are contested, because splitting aggressively creates shallow functions that force readers to jump between files. Extract a function when the name clarifies the call site, not to hit a line count.

Are comments bad?

No, but most comments are a symptom of an unclear name. Delete comments that restate the code and commented-out code that Git already remembers. Keep comments that explain why a decision was made, non-obvious external constraints, warnings about consequences, and legal headers.

How do I write cleaner code when AI generates most of it?

Review it against the same principles. Check for generic names, duplicated helpers that already exist in your codebase, unnamed literal values, comments that restate the code, and abstractions invented for a single caller. Generated code is fluent and conventional, which makes its problems easy to miss.

Key Takeaways

  • Clean code means code the next person can change safely, which is a different goal from satisfying a rulebook.
  • Naming is the highest-leverage habit for beginners and removes more confusion than any other single practice.
  • Functions should do one thing at one level of abstraction, but the two-to-four-line target is contested, including by the author who proposed it.
  • Named constants beat magic numbers whenever a literal encodes a decision somebody made.
  • Most comments should be deleted and replaced by better names, but why-comments, external constraints, and warnings are worth writing.
  • Formatting is a solved problem: a formatter and a linter should own it, not your review comments.
  • Duplication is often cheaper than the wrong abstraction, so wait until the third occurrence before extracting.
  • Reviewing AI-generated code against these principles is becoming the more valuable version of this skill.

Sources

Read more