Linters: Automatic Code Style Validation — A Complete Guide for Developers

Imagine that you are working in a team of five developers. One prefers single quotes, the other prefers double quotes. The third one puts a semicolon everywhere, the fourth one avoids them. The fifth uses four spaces for indentation, and you use two. The code starts to look like a patchwork quilt, and every code review turns into a formatting argument instead of a discussion of architecture. Sound familiar?

Linters were invented to solve such problems — tools for automatically checking code for compliance with certain style rules. They not only save time on code review, but also help to find potential errors even before the program is launched.

What is a linter and why do you need it

A linter (from English lint — "to clean from lint") is a static code analysis program that checks the source code for compliance with the specified rules without executing it. The term appeared back in 1978, when Stephen Johnson created the lint utility for the C language.

Modern linters solve several important tasks. They ensure code consistency in the project so that any developer can easily read and understand the code of their colleagues. Linters find potential errors, such as unused variables, typos in function names, or scope problems. They automate code style checks, freeing up time to discuss more important things during code reviews. In addition, linters help newcomers adapt to team standards faster and teach best practices.

Popular linters for different languages

For JavaScript and TypeScript, the most popular solution is ESLint. It is a flexible and extensible tool with a huge number of rules and plugins. ESLint allows you to customize rules for the needs of the project, use ready-made configurations from the community, automatically fix many problems and integrate with all popular code editors.

The Python ecosystem uses several tools at once. Pylint offers a comprehensive check with a large set of rules, Flake8 combines the capabilities of several tools into one, and Black works as an "uncompromising code formatter" with minimal configuration.

For PHP, the de facto standard is PHP_CodeSniffer, which checks the code for compliance with PSR standards and allows you to create your own validation rules. In the world of CSS and SCSS, Stylelint is popular with support for modern CSS and preprocessors.

How the linter works from the inside

The linter's work process can be divided into several stages. First, the source code is parsed into an abstract syntax tree (AST). Then the linter traverses this tree and applies the rules to each node, checking the code structure, variable names, formatting, and other aspects. After that, the linter collects all the problems found and generates a report indicating the file, line, and description of the problem. Finally, for some problems, the linter can automatically apply fixes.

Let's consider a simple example of working with ESLint. Let's say we have the following code:

function calculateSum(a,b) {
    var result = a + b
    console.log(unused)
    return result
}

ESLint will find several problems in it: there are no spaces after the comma in the function parameters, the outdated keyword var is used instead of const, there is no semicolon at the end of the line, and there is also a reference to an undefined variable unused.

Setting up ESLint for a Vue.js project

Let's take a closer look at setting up a linter for a real Vue.js project. First, install the necessary packages:

npm install --save-dev eslint eslint-plugin-vue @vue/eslint-config-prettier

Then create the .eslintrc.js configuration file in the project root:

module.exports = {
  root: true,
  env: {
    node: true,
    browser: true,
    es2021: true
  },
  extends: [
    'plugin:vue/vue3-recommended',
    'eslint:recommended',
    '@vue/prettier'
  ],
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: 'module'
  },
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off',
    'vue/multi-word-component-names': 'off',
    'vue/require-default-prop': 'error',
    'vue/no-unused-vars': 'warn'
  }
}

Add scripts to the package.json file to run the check:

{
  "scripts": {
    "lint": "eslint --ext .js,.vue src",
    "lint:fix": "eslint --ext .js,.vue src --fix"
  }
}

Now you can run the check with the npm run lint command or automatically fix the problems with the npm run lint:fix command.

Integration with the code editor

To see linter errors while writing code, you need to configure integration with the editor. For VS Code, install the ESLint extension from the marketplace and add .vscode/settings.json to the settings:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "vue"
  ]
}

Now, when saving a file, all fixable problems will be automatically fixed.

Setting rules: a balance between strictness and convenience

One of the most common questions is: how strict should the linter rules be? Too soft rules will not give the desired effect, and too strict rules will annoy developers and slow down work.

A good strategy is to start with a basic set of recommended rules and gradually adapt them to the team. Do not include all possible rules at once, choose those that really help to avoid errors. Use severity levels: error stops the build and requires mandatory correction, warn shows a warning, but does not block the work, and off completely disables the rule.

Agree with the team on controversial rules. For example, single or double quotes are not a question of correctness, but of agreement. Document the reasons for choosing specific rules so that new team members understand the logic of decisions.

Linter in CI/CD pipeline

A linter is really useful when it is integrated into the continuous integration process. This ensures that all code that enters the main branch complies with the standards.

Example configuration for GitHub Actions in the .github/workflows/lint.yml file:

name: Lint

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run lint

Now, every time you push or create a pull request, a code check is automatically triggered. If the linter finds errors, GitHub will mark the check as failed, and you will immediately see what needs to be fixed.

Automatic correction and formatters

Many linters can not only find problems, but also automatically fix them. ESLint with the --fix flag can fix formatting problems, place missing semicolons, fix quotes, and do much more.

However, it is better to use specialized tools for formatting the code. Prettier is an opinionated code formatter that formats code according to strict rules with minimal configuration. The combination of ESLint for code quality checking and Prettier for formatting has become the standard in the JavaScript community.

To avoid conflicts, use eslint-config-prettier, which disables all ESLint rules related to formatting:

npm install --save-dev prettier eslint-config-prettier

And add to .eslintrc.js:

extends: [
  'plugin:vue/vue3-recommended',
  'eslint:recommended',
  'prettier' // must be the last
]

Typical mistakes when using linters

The first common mistake is ignoring linter warnings. Developers add eslint-disable comments to disable checks instead of fixing problems. Use disable comments only in exceptional cases and always add an explanation of why the rule is disabled.

The second mistake is a lack of consistency in the team. If each developer uses their own local configuration, this negates all the benefits of the linter. Keep the configuration in the repository and make sure everyone uses the same settings.

The third mistake is too late implementation. Adding a linter to a large project with an existing code base is difficult. It is better to start from the very beginning of the project or implement it gradually: first for new files, then gradually refactor the old code.

Advanced features

Modern linters offer many advanced features. You can create your own validation rules for the specific requirements of your project. Plugins extend functionality: for example, eslint-plugin-security finds potential security vulnerabilities, eslint-plugin-a11y checks availability, and eslint-plugin-import controls the correctness of imports.

Integration with TypeScript via @typescript-eslint allows you to check typed code taking into account the type system. And custom configurations for different parts of the project (for example, different rules for the frontend and backend) help to flexibly configure the check.

Conclusion

Linters are not just a tool for picky perfectionists. This is a proven way to improve code quality, speed up code review, prevent errors, and create a unified style in the team. It's easy to start using a linter: choose the right tool for your programming language, set up the basic configuration, configure integration with the editor and CI/CD, and adapt the rules to the needs of the team. At first, it may seem that the linter only slows down the work and annoys with constant remarks. But after a week, you will notice how the code has become cleaner, and the code review is faster and more constructive. The linter will become your silent assistant, who monitors the quality of the code around the clock and never tires of reminding you of best practices.

Appendix Code offers interactive courses in Python, JavaScript and other technologies for developers of any level.

Join our Telegram channel, where we regularly share useful articles, analyze complex concepts in simple language and help solve emerging issues.

Learn together with an active developer community!