What is a linter and why your team should use it?

More and more teams have adopted linters and other static tools in their development process. Some integrated them in the IDE of their preference, others automated by running them as an additional step in their CI. Also, some run both ways.

What ‘s a linter, then?

According to Wikipedia, linter

is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.

The first linter was written by Stephen C. Johnson in 1978 while working in the Unix operating system at Bell Labs. After that, many other linters have appeared for different purposes and languages, not only C.

The first linters used to check the source code and find potential optimizations for compilers. But, over the years, many other checks and analysis would be included in the process of linting.

The usage of linters has also helped many developers to write better code for not compiled programming languages. As there is not compiling time errors, finding typos, syntax errors, uses of undeclared variables, calls to undefined or deprecated functions, for instance, helping developers to fix it faster and reduce bugs before execution.

SourceLevel is changing directions!

After October 1st, 2021, we will focus all our efforts on our (All-in-one) Analytics & Data Platform for Engineering Teams, thus we’re discontinuing the Automated Code Review feature.

Linters have evolved

Linters have evolved. They started with those simple checks, but nowadays, they are getting more and more sophisticated. They perform Static Analysis, enforce configuration flags, check for compliance with a given style-guide or security rule, and a lot more.

Let’s explore some of these checks and how they can be useful for you.

Static Analysis

Static Analysis means that automated software runs through your code source without executing it. It statically checks for potential bugs, memory leaks, and any other check that may be useful.

If you’re a Python developer, you may already know Radon. It can count the source lines of code (SLOC), comment lines, a blank line, and other raw metrics, but also, it can calculate a “Maintainability Index,” which may be very important in some projects.

That’s just an example. There are plenty of other linters that perform Static Analysis checks.

Free E-book: Click here to download the free e-book Decoding Code Review and Pull Requests. Get all the key points and best practices to implement a code review culture.

Code standardizing

From https://xkcd.com/1285/

Standardizing your code is a great way to move the conversation to a more productive level. Having a guideline and running linters against the codebase avoids aesthetical changes in your pull request, like replacing all tabs for spaces, indenting a variable assignment, or even line breaks after a given number of characters.

Maximizing meaningful changes takes your discussion to topics that matter, like architectural decisions, security issues, or potential bugs.

By the way, security issues and potential bugs also can be avoided by linters!

Security Issues

If you’re into Rails, you have probably heard about Brakeman. It’s a Static Analysis Security Tool. It’s beneficial to find potential security issues. For instance, it runs checks looking for SQL Injection when using ActiveRecord’s  #find_or_create_by and friends. It also adds checks for XSS, config options, and much more.

Ruby is not the only language with this kind of engine. SourceLevel supports lots of engines for different languages. Brakeman included.

Potential bugs

JavaScript has some tricks. One of the most famous is the difference between == and ===. It’s a good practice, and it avoids much debugging time, to always use ===. If you enable, for instance, ESLint to check for that, it can tell you what part of your code is using == and even replace it for you.

Performance improvements

Every experienced developer knows not only the importance of performing software but many tricks that improve it. The problem is: what about newcomers? How can you pass this knowledge forward? Even senior programmers can miss a technique or two. So, why not let an automation software do it for you?

Did you know that in CSS, the universal selector (*) may slow down a page loading time? Or that unqualified attribute selectors have the same performance characteristics as the universal selector? Avoiding them is good practice.

Many linters include a performance check. They can add different kinds of performance improvements for experienced and newcomers developers. CSSLint is just an example.

And many other aspects

To infinity and beyond! There are lots and lots of linters for different programming languages, configuration files, and even for software integrations. Any check that matters and can be automated may turn into a linter.

If you work in a particular scenario, you may have to write your linter, even though it’s not too likely in our industry. Checks for HTML Accessibility features, Internalization potential errors, grammar errors, and many others are already there, open-sourced, waiting for you to download, configure, and start using.

Benefits of linting

According to Ferit T., linting improves readability, removes silly errors before execution and code review. But, as mentioned, linting may do more complex jobs, like detecting code smells or performing static analysis of your codebase.

But, in practice, what are the advantages of linting?

It improves code review discussion level

If your Pull Request has no typos, nor unused variables, and is compliant with the style guide, the conversation tends to focus on the architecture point of view. That’s it. Pull Request is a great place to point performance issues, securities vulnerabilities, or suggesting better abstractions. You don’t need to get in that single or double quotes or tab vs. spaces discussion. It is a productivity gain for sure.

Makes code look like written by a single person

To the medium and long term having a reliable code base that looks like written by the same person is excellent. Maintainability and evolution are easier because everyone tends to understand what’s written faster and more precise. It prevents bugs, makes the job more joyful for developers, and accelerates the time to market of new features.

Gives visibility of your codebase health

Is your code healthy? You won’t know until you measure it. An exciting way of doing so is to adding a step in your CI/CD pipeline to measure the evolution of your code health status. Better than that, you can take action as soon as possible when you see its health to decay. Such actions may imply on creating technical debit cards in your board or even raise the issue during your agile retrospective or architecture committee meeting.

Spreads awareness and ownership over code quality

Experienced developers can look into a diff and raise relevant issues about the proposed change. They probably know where to look: are variables names descriptives? How many lines does a method take? Is there any superclass?

But how about newcomers? The knowledge in a team is often heterogeneous. It means not every developer knows what to look over the code. Having a linter to tell where code smells are automatically is an excellent way to spread this knowledge and make the team responsible for the changes.

Quality is not a single-person responsibility. It’s essential to measure and control code quality over time. Otherwise, the code gets messy, which slows down development and time to market.

Controls technical debts

As many modern linters look for possible technical debts, like code smells, style guide mismatches, or poorly designed code (deep chains of if statements, or too complex methods, for instance), linters correlates with technical debt.

Making technical debts explicit during the code review process help software developers or engineers to spot, discuss, and fix it before the merge into the master  branch. It’s a very convenient practice which controls the technical debt insertions.

Examples of linters

There are a vast number of linters out there. Depending on the programming language, there are even more than one linters for each job. For instance, for the Go programming language, there are ktlint and detekt. Both perform a similar job. The same happens to eslint, a linter designed for JavaScript. It works very similar to tslint or jshint.

Linters focused on Security

• Brakeman for Ruby
• Bandit for Python
• Node Security for JavaScript
•  

Linters focused on the style guide and coding conventions

• CSSLint. SCSS Lint and Sass Lint for Cascading Style Sheet
• Gofmt for Go language
• Swiftlint for Switft
• rustfmt for Rust
• Credo for Elixir

Linters for Static Analysis

• pep8 for Python
• Phan or PHP Mess Detector for PHP
• kibit for Clojure, ClojureScript, cljx, and other Clojure variants.
• PMD for Java

Conclusion

Linters help you get more productive and save you time and money. They drive your team to better decisions (those oriented by data) and share ownership over the quality.

[wd_hustle id=”9″ type=”embedded”/]