# 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**

{% hint style="info" %}
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](https://google.github.io/styleguide/) - which is open source
{% endhint %}

### 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:

```bash
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

{% hint style="info" %}
It's a good idea to make LINT be another unit test within your CI
{% endhint %}

* Even better solution in CI: 

{% hint style="info" %}
Automatically fix the issues too
{% endhint %}

```docker
COPY . . 
RUN if ! npm run eslint; then \ 
        npm run eslint --fix && \
        git config user.name 'lint bot' && \
        git config user.email 'lint@bot.com' && \
        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:

{% hint style="info" %}
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
{% endhint %}

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