# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.arkannis.net/general-concepts/devops/linting-best-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.