Code Style and Formatting

Use ECMAScript features from stage 2 and higher

ECMAScript (ES) is the standardized specification for JavaScript, and new versions of the specification are released in stages, with stage 0 being the earliest and stage 4 being the final stage before being finalized. Stage 2 features are proposed and being standardized, but they have not yet been finalized and may still change.

Using Stage 2 features allows access to newer features and can help stay current with the latest developments in the language, but carries the risk of using features that may still change before being finalized.

Avoid fixed-form syntax

Fixed-form syntax is a type of syntax used in programming languages in which the placement of white space, indentation, and line breaks is significant and must be followed exactly in order for the code to be correct.

Contrary to the free-form syntax, fixed-form syntax is inflexible and can make code less readable and maintainable, so it is generally recommended to avoid it.

// 🚫 Bad
if (a > b)
  doSomething(); 
  doSomethingElse(); // This will be excuted even if a <= b
 
// ✅ Good
if (a > b) {
  doSomething();
  doSomethingElse();
}

Use Prettier to enforce formatting

Prettier (opens in a new tab) is a widely accepted tool in the development community for enforcing a consistent formatting. Using Prettier can help ensure that code adheres to accepted standards and conventions.

Use default options of Prettier

Use the default options of Prettier unless you have a specific need to modify it.

Prettier is opinionated and follows specific rules and guidelines for formatting code. Its goal is to stop debates over coding styles, so modifying the default options goes against this goal and the Prettier option philosophy (opens in a new tab).

Use a .editorconfig file

It is recommended to use both EditorConfig (opens in a new tab) and Prettier together in order to enforce formatting rules that are not covered by Prettier, like the charset, as well as to apply formatting rules to files that Prettier does not support.

Here is a pre-configured .editorconfig file that you can copy and paste into your project if you use the default options of Prettier:

[*]
charset = utf-8
insert_final_newline = true
end_of_line = lf
indent_style = space
indent_size = 2
max_line_length = 80

If you have customized the options for Prettier and want to use EditorConfig to enforce your preferred formatting rules, you can refer to the Prettier documentation (opens in a new tab) for guidance on how to configure Prettier with EditorConfig.

Use ESLint to enforce code style

Using ESLint (opens in a new tab) can help enforce a consistent code style and ensure that code adheres to best practices and standards. This can make code easier to read and understand, and can also help catch potential issues and errors before they become a problem.

Use a popular ESLint style guide

Start by using a popular ESLint style guide, and then make any necessary adjustments to fit the specific needs of your project.

Using a popular ESLint style guide can help ensure that code follows accepted standards and conventions within the development community. This can make code easier for other developers to read and understand, and can also make it easier to collaborate and work on projects with others.

There are many popular style guides that use ESLint to enforce coding standards and style rules. Here are a few examples:

• Airbnb (opens in a new tab): Widely used and has a set of rules and guidelines for writing clean, consistent, and readable JavaScript code. It covers a wide range of topics, including naming conventions, code formatting, and best practices for writing and organizing code.
• Standard (opens in a new tab): Based on the idea of "no configuration" and aims to provide a simple, clean, and consistent set of rules for writing JavaScript code. It covers a wide range of topics, including naming conventions, code formatting, and best practices for writing and organizing code.
• Google (opens in a new tab): Used by Google and provides a set of rules and guidelines for writing clean, consistent, and readable JavaScript code. It covers a wide range of topics, including naming conventions, code formatting, and best practices for writing and organizing code.
• Idiomatic (opens in a new tab): Based on the idea of writing "idiomatic" JavaScript code and provides a set of rules and guidelines for writing clean, consistent, and readable code. It covers a wide range of topics, including naming conventions, code formatting, and best practices for writing and organizing code.
• Peppy (opens in a new tab): Cloned from the Airbnb style guide and focuses on writing modern, concise, and maintainable JavaScript code. It provides rules and guidelines for clean, consistent, and readable code, covering topics like naming conventions, code formatting, and best practices for writing and organizing code.

As the creator of Peppy, I naturally encourage you to use this guide style. If you already use the Airbnb guide style, you won't be in an unfamiliar territory since Peppy is cloned from Airbnb. Unlike the latter, however, it supports TypeScript natively, doesn't conflict with Prettier, supports modern JavaScript, doesn't require you to manually install and maintain all its peer dependencies, and came with a CLI to help you install it and set up your project easily.

Use a .eslintignore file

A .eslintignore file allows you to specify which files and directories should be excluded from linting, which can be useful if you want to exclude certain files that do not need to be checked or do not adhere to the same coding standards as the rest of the project.

Use eslint-disable sparingly

Overuse of eslint-disable can make it difficult to understand and maintain the code, and can also make it harder to catch and fix issues.

Although there may be times when it is necessary to disable a particular ESLint rule on a file, it is important to include an additional comment with your eslint-disable comment to explain why the rule is being disabled in this instance to help with understanding and maintaining the code.

// eslint-disable-next-line security/detect-non-literal-regexp  -- Sanitized index value that doesn't came from user inputs. Safe operation.
const stringInterpolateRegex = new RegExp(`\\{${index}\\}`, "g");

Use automated code style and formatting validations

Using automated code style and formatting validations can help ensure that code is consistent, readable, and adheres to best practices and standards, which can save time and effort in code review, maintenance and collaboration.

Learn more