How to write elegant JS code

variable

Use meaningful and pronounceable variable names
Use the same vocabulary for variables of the same type
Use searchable names
Using explanatory variables
Eliminate the guesswork
No need to add unnecessary context
Use default parameters instead of logical OR (AND) operations

function

Function parameters (ideally 2 or less)
Functions should do only one thing
Function names should describe what they do
Functions should have only one level of abstraction
Remove duplicate code
Setting a default object using Object.assign
Don't use flags as function arguments
Avoiding Side Effects (Part 1)
Avoiding Side Effects (Part 2)
Don't write global functions
Use functional programming instead of imperative programming
Packaging conditions
Avoid using non-conditionals
Avoid using too many conditions
Avoid type checking
Don't over-optimize

variable

Use meaningful and pronounceable variable names

// Bad way to write const yyyymmdstr = moment().format("YYYY/MM/DD");

// Good way to write const currentDate = moment().format("YYYY/MM/DD");

Use the same vocabulary for variables of the same type

// Bad way to write getUserInfo();
getClientData();
getCustomerRecord();

// Good way to write getUser();

Use searchable names

We read much more than we write, so if the naming is too arbitrary, it will not only make subsequent maintenance difficult, but also hurt the developers who read our code. Make your variable names human-readable; tools like buddy.js and ESLint can help identify unnamed constants.

// Bad writing // What is the purpose of 86400000?
setTimeout(blastOff, 86400000);

// Good writing const MILLISECONDS_IN_A_DAY = 86_400_000;
setTimeout(blastOff, MILLISECONDS_IN_A_DAY);

Using explanatory variables

// Bad writing const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\s]+(.+?)\s*(\d{5})?$/;
saveCityZipCode(
  address.match(cityZipCodeRegex)[1],
  address.match(cityZipCodeRegex)[2]
);


// Good writing const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\s]+(.+?)\s*(\d{5})?$/;
const [_, city, zipCode] = address.match(cityZipCodeRegex) || [];
saveCityZipCode(city, zipCode);

Eliminate the guesswork

Explicit for implicit

// Bad syntax const locations = ["Austin", "New York", "San Francisco"];
locations.forEach(l => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  // Wait, what is "l" again?
  dispatch(l);

// Good writing const locations = ["Austin", "New York", "San Francisco"];
locations.forEach(location => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  dispatch(location);
});

No need to add unnecessary context

If the class name/object name is already stated, there is no need to repeat it in the variable name.

// Bad writing const Car = {
  carMake: "Honda",
  carModel: "Accord",
  carColor: "Blue"
};

function paintCar(car) {
  car.carColor = "Red";
}
// Good writing const Car = {
  make: "Honda",
  model: "Accord",
  color: "Blue"
};

function paintCar(car) {
  car.color = "Red";
}

Use default parameters instead of logical OR (AND) operations

// Bad writing function createMicrobrewery(name) {
  const breweryName = name || "Hipster Brew Co.";
  // ...
}
// Good practice function createMicrobrewery(name = "Hipster Brew Co.") {
  // ...
}

function

Function parameters (ideally 2 or less)

Limiting the number of function parameters is very important because it makes it easier to test the function. If there are more than three parameters, there will be a combinatorial explosion, and a large number of different cases must be tested with each individual parameter.

One or two parameters are ideal, and three parameters should be avoided if possible. In addition, it should be merged. In most cases, more than three parameters can be replaced by objects.

// Bad writing function createMenu(title, body, buttonText, cancellable) {
  // ...
}

createMenu("Foo", "Bar", "Baz", true);

// Good writing function createMenu({ title, body, buttonText, cancellable }) {
  // ...
}

createMenu({
  title: "Foo",
  body: "Bar",
  buttonText: "Baz",
  cancellable: true
});

Functions should do only one thing

This is by far the most important rule in software engineering. When functions do more than one thing, they are harder to compose, test, and reason about. When you can isolate a function into a single operation, it is easier to refactor it and the code reads more clearly.

// Bad writing function emailClients(clients) {
  clients.forEach(client => {
    const clientRecord = database.lookup(client);
    if (clientRecord.isActive()) {
      email(client);
    }
  });
}

// Good writing function emailActiveClients(clients) {
  clients.filter(isActiveClient).forEach(email);
}

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

Function names should describe what they do

// Bad way to write function addToDate(date, month) {
  // ...
}

const date = new Date();

// It's hard to tell what to add from the function name addToDate(date, 1);

// Good way to write function addMonthToDate(month, date) {
  // ...
}

const date = new Date();
addMonthToDate(1, date);

Functions should have only one level of abstraction

When there is more than one level of abstraction in a function, it means that the function is doing too much and needs to be broken up for reusability and easier testing.

// Bad way to write function parseBetterjsAlternative(code) {
  const REGEXES = [
    // ...
  ];

  const statements = code.split(" ");
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      // ...
    });
  });

  const ast = [];
  tokens.forEach(token => {
    // lex...
  });

  ast.forEach(node => {
    // parse...
  });
}

// Good way to write function parseBetterJSAlternative(code) {
  const tokens = tokenize(code);
  const syntaxTree = parse(tokens);
  syntaxTree.forEach(node => {
    // parse...
  });
}

function tokenize(code) {
  const REGEXES = [
    // ...
  ];

  const statements = code.split(" ");
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      tokens.push(/* ... */);
    });
  });

  return tokens;
}

function parse(tokens) {
  const syntaxTree = [];
  tokens.forEach(token => {
    syntaxTree.push(/* ... */);
  });

  return syntaxTree;
}

Remove duplicate code

Try to avoid duplicate code. Duplicate code is bad, it means if we need to change some logic, we have to change a lot of places.

Often, there is duplicate code because there are two or more slightly different things that have a lot in common, but their differences force us to write two or more separate functions to do many of the same things. Removing duplicate code means creating an abstraction that handles this set of different things with just one function/module/class.

Getting the abstraction right is crucial, which is why we should follow the SOLID principles listed in the classes section. Bad abstractions can be worse than duplicate code, so be careful! Having said all that, if you can make a good abstraction, do it! Don't repeat yourself or you'll find yourself updating multiple places any time you want to change one thing.

The six principles of design patterns are:

Single Responsibility Principle
Open Closed Principle: Open Closed Principle
Liskov Substitution Principle: Liskov Substitution Principle
Law of Demeter:
Interface Segregation Principle: Interface Segregation Principle
Dependence Inversion Principle

Combining the first letters of these six principles (two Ls count as one) is SOLID (solid), which represents the benefit of using these six principles together: establishing a stable, flexible, and robust design. Let’s take a look at these six design principles one by one.

Bad writing

function showDeveloperList(developers) {
  developers.forEach(developer => {
    const expectedSalary = developer.calculateExpectedSalary();
    const experience = developer.getExperience();
    const githubLink = developer.getGithubLink();
    const data = {
      expectedSalary,
      experience,
      githubLink
    };

    render(data);
  });
}

function showManagerList(managers) {
  managers.forEach(manager => {
    const expectedSalary = manager.calculateExpectedSalary();
    const experience = manager.getExperience();
    const portfolio = manager.getMBAProjects();
    const data = {
      expectedSalary,
      experience,
      portfolio
    };

    render(data);
  });
}

Good writing

function showEmployeeList(employees) {
  employees.forEach(employee => {
    const expectedSalary = employee.calculateExpectedSalary();
    const experience = employee.getExperience();

    const data = {
      expectedSalary,
      experience
    };

    switch (employee.type) {
      case "manager":
        data.portfolio = employee.getMBAProjects();
        break;
      case "developer":
        data.githubLink = employee.getGithubLink();
        break;
    }

    render(data);
  });
}

Setting a default object using Object.assign

Bad writing

const menuConfig = {
  title: null,
  body: "Bar",
  buttonText: null,
  cancellable: true
};

function createMenu(config) {
  config.title = config.title || "Foo";
  config.body = config.body || "Bar";
  config.buttonText = config.buttonText || "Baz";
  config.cancellable =
    config.cancellable !== undefined ? config.cancellable : true;
}

createMenu(menuConfig);

Good writing

const menuConfig = {
  title: "Order",
  // User did not include the 'body' key
  buttonText: "Send",
  cancellable: true
};

function createMenu(config) {
  config = Object.assign(
    {
      title: "Foo",
      body: "Bar",
      buttonText: "Baz",
      cancellable: true
    },
    config
  );

  // config now equals: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}
  // ...
}

createMenu(menuConfig);

Don't use flags as function arguments

The flag tells the user that this function can accomplish multiple tasks and that the function should do one thing. If functions follow different code paths based on booleans, split them up.

// Bad writing function createFile(name, temp) {
  if (temp) {
    fs.create(`./temp/${name}`);
  } else {
    fs.create(name);
  }
}

// Good writing function createFile(name) {
  fs.create(name);
}

function createTempFile(name) {
  createFile(`./temp/${name}`);
}

Avoiding Side Effects (Part 1)

A function has a side effect if it does nothing other than accept a value and return another value or values. A side effect could be writing to a file, modifying some global variable, or accidentally sending all your funds to a stranger.

Bad writing

let name = "Ryan McDermott";

function splitIntoFirstAndLastName() {
  name = name.split(" ");
}

splitIntoFirstAndLastName();

console.log(name); // ['Ryan', 'McDermott'];

Good writing

function splitIntoFirstAndLastName(name) {
  return name.split(" ");
}

const name = "Ryan McDermott";
const newName = splitIntoFirstAndLastName(name);

console.log(name); // 'Ryan McDermott';
console.log(newName); // ['Ryan', 'McDermott'];

Avoiding Side Effects (Part 2)

In JavaScript, primitive values are passed by value, while objects/arrays are passed by reference. For objects and arrays, if a function makes a change in a cart array (for example, by adding an item to purchase), any other function using that cart array will be affected by this addition. That could be great, but it could also be bad. Let's imagine a bad situation:

The user clicks a Buy button, which calls a purchase function, which in turn makes a network request and sends the cart array to the server. Due to poor network connectivity, the purchase function must continually retry the request. Now, what if, before the network request begins, the user accidentally clicks the "Add to Cart" button on an item they don't actually want? If this happens, and the network request begins, the purchase function will send the accidentally added item because it has a reference to the cart array, which the addItemToCart function modified by adding it.

A good solution would be for addItemToCart to always clone the cart array, edit it, then return the clone. This ensures that other functions referenced by the cart are not affected by any changes.

There are two things to note about this approach:

1. There may be some cases where we do need to modify the input object, but when we adopt this programming practice, we will find that this situation is very rare and most things can be transformed to have no side effects.

2. Cloning large objects can be very expensive in terms of performance. Fortunately, this isn't a huge problem in practice, as there are a lot of great libraries that make this method of programming fast and not as memory intensive as manually cloning objects and arrays.

// Bad way to write const addItemToCart = (cart, item) => {
  cart.push({ item, date: Date.now() });
};

// Good way to write const addItemToCart = (cart, item) => {
  return [...cart, { item, date: Date.now() }];
};

Don't write global functions

Polluting global variables is a bad practice in JS because there might be a conflict with another library and the users of your API will be left with nothing until they encounter an exception in production. Let's consider an example: what if you wanted to extend JS's native Array method to have a diff method that can show the differences between two arrays? It's possible to write a new function to Array.prototype, but it might conflict with another library that tries to do the same thing. What if other libraries only use diff to find the difference between the first and last element of an array? That's why it would be much better to just use ES6 classes and simply extend the Array global.

// Bad way to write Array.prototype.diff = function diff(comparisonArray) {
  const hash = new Set(comparisonArray);
  return this.filter(elem => !hash.has(elem));
};

// Good writing class SuperArray extends Array {
  diff(comparisonArray) {
    const hash = new Set(comparisonArray);
    return this.filter(elem => !hash.has(elem));
  }
}

Use functional programming instead of imperative programming

JavaScript is not a functional language like Haskell, but it has a functional style. Functional languages can be more concise and easier to test. If you can, try to prefer this style of programming.

Bad writing

const programmerOutput = [
  {
    name: "Uncle Bobby",
    linesOfCode: 500
  },
  {
    name: "Suzie Q",
    linesOfCode: 1500
  },
  {
    name: "Jimmy Gosling",
    linesOfCode: 150
  },
  {
    name: "Gracie Hopper",
    linesOfCode: 1000
  }
];

let totalOutput = 0;

for (let i = 0; i < programmerOutput.length; i++) {
  totalOutput += programmerOutput[i].linesOfCode;
}

Good writing

const programmerOutput = [
  {
    name: "Uncle Bobby",
    linesOfCode: 500
  },
  {
    name: "Suzie Q",
    linesOfCode: 1500
  },
  {
    name: "Jimmy Gosling",
    linesOfCode: 150
  },
  {
    name: "Gracie Hopper",
    linesOfCode: 1000
  }
];

const totalOutput = programmerOutput.reduce(
  (totalLines, output) => totalLines + output.linesOfCode,
  0
);

Packaging conditions

// Bad way to write if (fsm.state === "fetching" && isEmpty(listNode)) {
  // ...
}

// Good writing function shouldShowSpinner(fsm, listNode) {
  return fsm.state === "fetching" && isEmpty(listNode);
}

if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
  // ...
}

Avoid using non-conditionals

// Bad writing function isDOMNodeNotPresent(node) {
  // ...
}

if (!isDOMNodeNotPresent(node)) {
  // ...
}

// Good writing function isDOMNodePresent(node) {
  // ...
}

if (isDOMNodePresent(node)) {
  // ...
}

Avoid using too many conditions

It seems like an impossible task. Upon hearing this, most people say, “How can I do anything without if statements?” The answer is that you can use polymorphism to achieve the same task in many situations.

The second question is usually, "That's great, but why would I do that?" The answer is the concept I talked about above: a function should do only one thing. When you have classes and functions with if statements, you are telling your users that this function does more than one thing.

Bad writing

class Airplane {
  // ...
  getCruisingAltitude() {
    switch (this.type) {
      case "777":
        return this.getMaxAltitude() - this.getPassengerCount();
      case "Air Force One":
        return this.getMaxAltitude();
      case "Cessna":
        return this.getMaxAltitude() - this.getFuelExpenditure();
    }
  }
}

Good writing

class Airplane {
  // ...
}

class Boeing777 extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getPassengerCount();
  }
}

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

class Cessna extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getFuelExpenditure();
  }
}

Avoid type checking

JavaScript is untyped, which means that functions can accept arguments of any type. Sometimes we get bothered by this freedom and want to type check our functions. There are many ways to avoid doing this. The first thing to consider is a consistent API.

// Bad way to write function travelToTexas(vehicle) {
  if (vehicle instanceof Bicycle) {
    vehicle.pedal(this.currentLocation, new Location("texas"));
  } else if (vehicle instanceof Car) {
    vehicle.drive(this.currentLocation, new Location("texas"));
  }
}

// Good way to write function travelToTexas(vehicle) {
  vehicle.move(this.currentLocation, new Location("texas"));
}

Don't over-optimize

Modern browsers do a lot of optimization work at runtime. A lot of times, if you’re optimizing, you’re just wasting time. There are great resources out there to see where optimization is lacking, we just need to target the areas that need optimization.

// Bad practice // On older browsers, each iteration with uncached 'list.length' is expensive // as 'list.length' will be recalculated. In modern browsers, this is optimized for (let i = 0, len = list.length; i < len; i++) {
  // ...
}

// Good way to write for (let i = 0; i < list.length; i++) {
  // ...
}

The above is the details of how to write elegant JS code. For more information about elegant JS code, please pay attention to other related articles on 123WORDPRESS.COM!

You may also be interested in:

js simple network speed test method complete example
Access the javascript code for Baidu and Google speed test
JS asynchronous code unit testing magic Promise
Native js implements regular validation of the form (submit only after validation)
Detailed explanation of reduce fold unfold usage in JS
How to use JS WebSocket to implement simple chat
Detailed explanation of common usage methods of weixin-js-sdk in vue
Detailed explanation of JS homology strategy and CSRF
How to test network speed with JavaScript

<<: MySQL intercepts the sql statement of the string function

>>: Ubuntu 16.04 image complete installation tutorial under VMware