Linting best practices

• Linters look at a program's soruce code and find problems automatically.

• They are a common feature of pull request automations because they ensure that "obvious" bugs do not make it to PROD

It's usually a good idea to follow a style guide to avoid resentment within engineering teams

One such example is the Google Style Guide - which is open source

The NIT approach

• Code reviewers leave little comments on the code called "nits" that the team can ignore until broader reviews.

• Nits are helpful as future references but prevent blocking important changes

Auto Formatter

• Tools that help apply code style rules based on the style guide your team has chosen automatically

Example for GO:

find . -name '.go' -not -path "/vendor/*" -exec gofmt -s -w {} ;

Linting automatically in CI

• Developers should never wait for a human reviewer to let them know if their code is linted and styled correctly

• Cheap and convenient to run linting and formatting within CI steps

It's a good idea to make LINT be another unit test within your CI

• Even better solution in CI:

Automatically fix the issues too

COPY . . 
RUN if ! npm run eslint; then \ 
        npm run eslint --fix && \
        git config user.name 'lint bot' && \
        git config user.email '[email protected]' && \
        git add -A &&
        git commit -m 'Automatically linted' && \
        git checkout -b $(git branch --show-current)-linted && \
        git push -f origin $(git branch --show-current)-linted; && \
        echo 'line failed!'; exit 1; \
    fi

Examples of linters:

Python: pylint, flake8

GO: gofmt

SonarQube - used for a lot of languages - Static analisis (looking at source code without running it)

DeepSource - used for a lot of languadges + Terraform

DeepSource pricing can be found here: https://deepsource.com/pricing/

Any team with more than one developer working in the same codebase should setup a linter to catch obvious bugs