Lint, what and why

The problem:

The statement “Time is money” makes more and more sense among programmers, being efficient allows more jobs in less time and you certainly don't want to waste your hours behind a ghost character or a dead code due to a lack of attention during development.

Spending hours developing an application can be exhausting, and it gets worse when we finally test it and "CRASH!". (Let's go back there in the code to resolve this).
After a few more hours it turns out that the problem was the lack of a single character in the code.

Well, the top case is probably the daily life of many developers, and without a doubt it is one of the oldest problems in programming.

The solution:

"We are going to write a program that checks the code to find possible syntax errors, infinite loops, dead codes, etc."

In 1978 a computer scientist working for Bell Labs named Stephen C. Johnson created a program for checking static code in C, currently we have Linters for virtually all commercial programming languages, and at development time they point out flaws in our code that could even pass as a structural or logical problem in our application, making us spend hours and hours behind the problems.

When to use?
“Prevention is better than cure”, so always, always use Linters in your projects, no matter the size and duration.

But which linter should I use?
The https://github.com/mcandre/linters repository is an extremely useful source for you to find the best one for your language and need.

Automation:
Okay, it is useless to use a tool to prevent errors caused many times by lack of attention, but forget to use it.
So there are several ways to automate the code checking process, let's talk about my two favorites.

1. Git Hooks. (My favorite)
   During pre-commit, set up a command to perform the inspection of your code using your preferred linter, so the chance of sending broken code to your repository is minimal.

2. CI
   If you are using GitFlow, you will probably code your feature in a specific branch for it, and when your work is done if you create a merge request for the development branch, use your Git Host resources (GitHub or GitLab) to set up a CI process that executes a command to check your code before asking another developer to approve it, that way, not only is your time saved, but it helps to save the time of the rest of the team.