Clean Code JavaScript

This is a fundamental rule: functions should be isolated to a single action. When a function performs multiple tasks, it becomes harder to compose, test, and reason about. If you find a function doing multiple things, refactor it into smaller, specialized functions.

// Good: Breaking complex logic into single-purpose functions
function emailActiveClients(clients) {
  clients.filter(isActiveClient).forEach(email);
}

function isActiveClient(client) {
  const clientRecord = database.lookup(client);
  return clientRecord.isActive();
}

When modeling data, prefer composition (a "has-a" relationship) over inheritance (an "is-a" relationship) where possible.

When to use Inheritance:

1. The relationship is strictly "is-a" (e.g., Human is an Animal).
2. You need to reuse code from base classes.
3. You want to make global changes to all derived classes via a single base class change.

When to use Composition:

If the relationship is "has-a" (e.g., an Employee has TaxData, but an Employee is not a type of TaxData), use composition by storing the related object as a property within the main class.

class EmployeeTaxData {
  constructor(ssn, salary) {
    this.ssn = ssn;
    this.salary = salary;
  }
}

class Employee {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  setTaxData(ssn, salary) {
    this.taxData = new EmployeeTaxData(ssn, salary);
  }
}

A class should have only one reason to change. Avoid 'jam-packing' a class with multiple functionalities, as this reduces conceptual cohesion and makes it difficult to predict how changes to one part of the class will affect other modules. Instead, split responsibilities into separate, specialized classes.

// Good: Responsibilities are split into UserAuth and UserSettings
class UserAuth {
  constructor(user) {
    this.user = user;
  }

  verifyCredentials() {
    // ...
  }
}

class UserSettings {
  constructor(user) {
    this.user = user;
    this.auth = new UserAuth(user);
  }

  changeSettings(settings) {
    if (this.auth.verifyCredentials()) {
      // ...
    }
  }
}

A function should ideally take a value and return a value without affecting anything else. Side effects include modifying global variables, writing to files, or mutating input arguments.

To manage side effects:

1. Centralize them: Instead of having many functions write to a file, use a single dedicated service.
2. Avoid mutating inputs: When dealing with mutable types like Objects and Arrays, always clone the input, modify the clone, and return it. This prevents unexpected bugs in other parts of the application that hold references to the original data.

// Good: Avoiding mutation by returning a new array (cloning)
const addItemToCart = (cart, item) => {
  return [...cart, { item, date: Date.now() }];
};

Large switch or if/else blocks that check a type to decide behavior are often a sign that you should use polymorphism. Instead of checking a type property, define a common interface and implement specific behaviors in subclasses.

// Good: Using polymorphism instead of a switch statement
class Boeing777 extends Airplane {
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getPassengerCount();
  }
}

class AirForceOne extends Airplane {
  getCruisingAltitude() {
    return this.getMaxAltitude();
  }
}

In environments where ES6 private class fields are not used (or for ES5 and below), you can achieve true privacy by using closures. By defining variables within a factory function and only exposing specific methods via the returned object, the internal state remains inaccessible from the outside, even if properties are deleted from the returned object.

function makeEmployee(name) {
  return {
    getName() {
      return name;
    }
  };
}

const employee = makeEmployee("John Doe");
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
delete employee.name;
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe

A function should not mix different levels of abstraction. If a function contains low-level implementation details (like regex parsing) alongside high-level orchestration (like building an AST), it is doing too much. Split these into separate functions to improve reusability and testability.

// Good: High-level orchestration function
function parseBetterJSAlternative(code) {
  const tokens = tokenize(code);
  const syntaxTree = parse(tokens);
  syntaxTree.forEach(node => {
    // parse...
  });
}

// Low-level implementation functions
function tokenize(code) { /* ... */ }
function parse(tokens) { /* ... */ }