Clean Code in JavaScript

main takeaway


Tenets of Clean Code



It is vital to start with the user and their problem; from that, we can establish a set of clear requirements that can be independently tested.


The continued correct behavior given different valid inputs and situations.

The way to stability is through having a full understanding of all different valid/invalid inputs.

Stability is validated with a test suite that exposes the code to various inputs and situations.


aka fault tolerance.

The examples in the book are interesting:

  1. An escalator, when functioning correctly, will convey people via a set of moving metallic steps (...). If the system fails, then the escalator remains static, acting as a regular flight of stairs.
  2. An application that delivers the transcription of an audio if the client is unable to play mp3 content.

My note: this "fault tolerance" talk made me remember the Rule of Repair (The Art of Unix Programming):

Repair what you can - but when you must fail, fail noisily and as soon as possible.

(...) write your software to cope with incorrect inputs and its own execution errors as gracefully as possible. But when it cannot, make it fail in a way that makes diagnosis of the problem as easy as possible.


Pretty obvious... "Don't be slow."

This topic makes me remember the Response-Time Limits for humans.



Two harmful characteristics that might cause trouble: fragility and rigidity


Most software, regardless of the problem domain, will have the concept of create, read, update, and delete (CRUD). These make up the famous verbs of persistence storage. Most software can be thought of as fancy middleware sitting atop persistent storage.


I liked this way of listing the group of users of our work:

My thoughts after realizing the existence of this second group:

We, as coders, should be defending the interests of that second group. Here are the reasons:

User stories

User stories typically take the following form:

As a [persona], I want to [want], so that [purpose]...

The Enemies of Clean Code

None of these enemies should be considered your enemies; instead they should be thought of as agitators of clean code.

  1. JavaScript
  2. Management
  3. Self
  4. The cargo cult

Enemy 1 - JavaScript

My words: The "accessibility" of JavaScript makes it usable by newbies, who produce messy code.

Enemy 2 - management

Pressure to ship

For the "pressure to ship" part, I like remember the Clean Code - 1. Clean Code:

Quality vs. Business Pressure -> Managers may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion.

Some heuristics to ensure a healthy code base:

Bad metrics

Over time if a metric is chased too ambitiously, it may end up corrupting the very thing it was trying to measure.

"When a measure becomes a target, it ceases to be a good measure."