clean-code-javascript

Clean Code JavaScript adapts the principles of Robert C. Martin's Clean Code for JavaScript. The README insists it is not a style guide but a guide to readable, reusable, refactorable software.

The README opens with a distinction. This is not a style guide; it is a guide to producing readable, reusable, and refactorable software in JavaScript, adapted from Robert C. Martin's Clean Code. It also says the principles are guidelines and nothing more, codified over years of collective experience. Not every rule must be followed, and even fewer will be universally agreed upon.

The guide argues we read more code than we write, so names should be searchable. Default parameters are preferred over short-circuiting or conditionals. Function arguments should stay at two or fewer, with ES2015 destructuring making the expected properties obvious. Above all, a function should do one thing, and stay at one level of abstraction.

Duplicate code means more than one place to change when logic shifts, so the guide says to remove it, with a restaurant inventory analogy as illustration. It warns that a bad abstraction can be worse than the duplication it replaces. Boolean flags should not appear as function parameters, because a flag tells the reader the function does more than one thing.

A function produces a side effect when it does anything besides taking a value in and returning a value, whether that is writing a file or mutating a global. Side effects are sometimes necessary, so the advice is to centralize them in one service rather than scattering them across classes. The guide also cautions about mutable objects and arrays passed as arguments, since they can cause bugs far from the call site.

The full table of contents covers variables, functions, objects and data structures, classes, SOLID, testing, concurrency, error handling, formatting, comments, and translation. The introduction closes on a forgiving note: every piece of code starts as a first draft, like wet clay, and reviews with peers are how the imperfections get chiseled away. Beat up the code, not yourself.

The guide knows its own limits. Not every principle must be followed, and few are universally agreed upon. It frames them as a touchstone for assessing the code you write, not a court of appeals.

• Source 1 · Project repository
• Source 2 · README