Mastering Prettier & ESLint: Clean Code Practices for Frontend Developers

Preface

Whether using open‑source code or project templates, we inevitably encounter lint tools such as ESLint and Prettier. Without understanding their purpose and differences, developers may mistakenly view them as unnecessary hassles. This article clarifies their relationship and discusses code standards and clean‑code importance for front‑end development.

Prettier and ESLint

Prettier

What?

When people think of code style, they often consider formatting details like indentation, semicolons, arrow‑function parentheses, or line length. Prettier is a code formatter that enforces a consistent style with few configuration options.

Official definition from Prettier:

Prettier is opinionated and offers few options, focusing solely on code formatting without checking code quality, which distinguishes it from ESLint.

Why?

Large open‑source front‑end projects (Ant Design Vue, Element UI, Vue 3, React, etc.) adopt Prettier to automatically enforce a uniform style, reducing the mental load of reviewing pull requests.

Building and enforcing a style guide without needing to discuss or learn rules.

Helping newcomers avoid low‑level mistakes.

One‑click formatting (e.g., Option+Shift+F) or format‑on‑save integration.

Maintaining a stable, opinionated format by limiting new configuration options.

ESLint

What?

Lint tools perform static analysis to ensure code quality. ESLint is a front‑end linting tool that checks both code quality (e.g., avoiding var, requiring default in switch) and style (e.g., semicolons, tabs vs. spaces).

Why?

JavaScript lacks a compile‑time type system, so ESLint provides static analysis to catch problematic patterns. Its rules are unopinionated and can be customized or disabled as needed.

How?

1. Install ESLint in a project: npm install eslint --save-dev 2. Initialize a configuration file: ./node_modules/.bin/eslint --init 3. In .eslintrc.js you can extend the recommended set:

{
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "double"]
  }
}

Run ESLint on a file: ./node_modules/.bin/eslint filePath.js When --fix is unavailable, combine ESLint with Prettier for automatic fixes. The --fix flag only repairs AST‑level issues (e.g., converting const b = data.a to destructuring, adjusting indentation, adding/removing semicolons) but does not change logical operators like == to ===.

Two common ways to fix ESLint problems:

Run ESLint with the --fix option from the command line.

Install the ESLint VSCode extension, which respects the project's .eslintrc and allows “format on save” or Option+Shift+F to auto‑format.

clean‑code

Because JavaScript has no compilation step, many hidden bugs go unnoticed without tools like ESLint.

Interview example: difference between for…in and for…of.

Initial answer: for…in iterates keys; for…of iterates values. ESLint later warns that for…in should be wrapped in an if to filter prototype properties.

Key distinctions:

for…in is suited for objects, iterates enumerable keys (including prototype properties) and yields string indices that cannot be directly incremented.

for…of works on iterable collections (arrays, strings, Map, Set) and iterates values, but cannot iterate plain objects.

ESLint rules no-iterator and no-restricted-syntax discourage for…in in favor of higher‑order functions ( map, reduce, forEach, etc.) or Object.keys/values/entries for object traversal.

What?

clean‑code‑javascript is a repository that adapts Robert C. Martin’s “Clean Code” principles to JavaScript.

“Code quality is proportional to its cleanliness. Clean code is more reliable and easier to maintain.”

The guide is organized into nine chapters: variables, functions, objects & data structures, classes, tests, async, error handling, formatting, and comments.

Why?

Rudolf Clausius: “The entropy of the universe tends to a maximum.”

Applying entropy to code: without external effort (linting, reviews), a project's codebase becomes increasingly chaotic. Reducing entropy requires deliberate actions such as static analysis and disciplined coding.

How?

Typical workflow:

1. Pre‑commit stage: combine husky (or pre‑commit) with lint‑staged to run Prettier and ESLint before committing. React’s create‑react‑app already integrates lint‑staged.

2. Team code review: use a PR workflow where multiple reviewers approve changes before merging.

Summary

Because JavaScript lacks a compile step, teams should use Prettier to enforce a uniform style and ESLint for static quality checks, thereby lowering code entropy. Understanding the rationale behind ESLint rules further improves code readability and moves the codebase toward front‑end clean‑code practices.

References:

clean‑code‑javascript: https://github.com/ryanmcdermott/clean-code-javascript

“Clean Code” book: https://book.douban.com/subject/4199741/

husky: https://www.npmjs.com/package/husky

pre‑commit: https://www.npmjs.com/package/pre-commit

lint‑staged: https://www.npmjs.com/package/lint-staged