What is Linting? How does a linter work?
Software developers know that programming errors are bad. Some errors cause glitches that frustrate users. Others compromise the safety and security of a critical system. No matter what type of program you’re developing, avoiding these errors is important. That’s why many development teams rely on linting. So what is linter or linting?
Here is the outline to answer this question: We start by defining the term “linter.” We will continue with a brief history. Then, we talk about the benefits of linters and proceed to talk about the different types of checks they offer.
Finally, we show you several examples of linters in the developers’ world, give some practical tips on how to get started, and wrap-up with a few final considerations.
Lint, or a linter, is a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs.
Linting is a process by a linter program that analyzes source code in a particular programming language and flag potential problems like syntax errors, deviations from a prescribed coding style or using constructs known to be unsafe. In short, a linter is a tool to help you improve your code.
The term “lint” was derived from the name of the tiny bits of fiber and fluff shed by clothing, as the computer command should act like a dryer machine lint trap, detecting small errors with big effects.
The term originates from a Unix utility that examined C language source code. Stephen C. Johnson, a computer scientist at Bell Labs, came up with lint in 1978 while debugging the yacc grammar he was writing for C and dealing with portability issues stemming from porting Unix to a 32-bit machine. In 1979, lint was used outside of Bell Labs for the first time in the seventh version of the Unix operating system.
Both the original lint tool, as well as earlier similar utilities, had the goal of analyzing source code to come up with compiler optimizations. Over time, lint-like tools started adding many other types of checks and verification.
Even though modern compilers have evolved to include many of lint’s historical functions, lint-like tools have also evolved to detect an even wider variety of suspicious constructs. Lint tools are the most basic form of static analysis. Using lint tools can be helpful for identifying common errors, such as:
- Indexing beyond arrays.
- Dereferencing null pointers.
- (Potentially) dangerous data type combinations.
- Unreachable code.
- Non-portable constructs.
Where to Use Lint?
A linter is great for identifying errors when you use standard rules. Remember, a linter analyzes your code for stylistic and programming errors against the rules it knows. This can depend on your programming language. Some languages are better suited for code linting than others.
For example, when it comes to compiled languages, such as C and C++, using lint software might not be enough. C and C++ are complex and may require more advanced code analysis.
On the other hand, we could say that linters are way more valuable for interpreted languages since there’s no compiler to detect errors during development time. Take Python and JavaScript, they lack a compiling phase. So, using lint software is effective for ensuring consistent coding style and resolving basic coding errors in these cases.
When it comes to code review, a linter may not exactly be a code review tool; however, it is considered as an essential part of the review process. Linters can be used for two base functions: to make developers follow the syntax requirements of any language, and to enforce stylistic guidelines.
The former shortens the code review process by catching faulty code as early as possible. The latter helps reviews by making sure all the code in the project is typed in the same format. So, it stays consistent, easily readable and saves time and effort on stylistic checks during reviews.
Pros & Cons
Now up to this point, you probably at least a general idea of what a linter can do for your code. But in more practical terms, what are the benefits that this type of tool can provide? Here are some:
- Fewer errors in production. The use of linters helps to diagnose and fix technical issues — e.g. code smells — in the code. As a result, fewer defects make their way to production.
- Readable, maintainable, and more consistent code. Linters can help teams achieve a more readable and consistent style, through the enforcement of its rules.
- Fewer discussions about code style and aesthetic choices during code reviews. Code review discussions shouldn’t be riddled with endless arguments about stylistic preferences. Linters can take those topics out of the way.
- Objective measurement of code quality. Discussions about code quality often veer into subjectivity. Linters provide an objective and measurable assessment of code quality.
- More secure and performant code. Not all linters analyze source code regarding its performance and safety, but some do.
- Education about code quality reaches more developers. Linters can help developers — particularly the most inexperienced ones — to learn about code quality.
As you may guess, every positive approach might have disadvantages as well. Here are some of them for linting:
- The most obvious argument against it is about it breaking concentration. If you are trying to get into the flow and crank out lines of code, a bunch of flags and warnings popping up can take you out of it.
- Another danger is developing warning fatigue. This is often the result of false negatives and making assumptions about the reliability of linters. If you get into the habit of ignoring all the flags, your linter can protect you as little as the warm, fuzzy-feeling you get inside from gazing at the ever-present check engine light.
- Using a linter on a massive existing code base is something many would advise against as “implementing a linter on a mature project becomes a tremendous task.”
Notwithstanding these disadvantages, as one developer point out in this stackoverview contribution: “Something I think that programmers don’t always appreciate is that linting isn’t an either/or proposition necessarily. A linter is exactly like the spelling/grammar checker in your word processor. It’s there to advise you.”
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.
Linters focused on the style guide and coding conventions
- ESLint, StantdartJS, JSLint for JavaScrtip
- CSSLint, SCSS Lint and Sass Lint for Cascading Style Sheet
- Black , PyLint for Python
- Gofmt for Go language
- Swiftlint for Switft
- rustfmt for Rust
- Credo for Elixir
And finally, it would worth mentioning Prettier, which is a special addition to this list. It’s not a fully realized linter. It’s basically a formatting ruleset you can plug into linters. It doesn’t touch the code itself, only it’s format, and it automatically reprints it in sync with the style guidelines.
Linters focused on Security:
- Brakeman for Ruby
- Bandit for Python
- Node Security for JavaScript
The next section covers some of the types of verifications that linters provide. After reading it, you’ll understand how linters provide the advantages mentioned above.
Types of Checks Linters Provide
As you’ve just read, the original lint tool analyzed code to enable optimizations for compilers, but over time, more advanced and complete tools were released. Nowadays, we have myriad different linters, which provide many types of checks. Let’s quickly go through some of them.
Syntax Errors
The most basic and more vital type of checks that a linter can provide are syntax error verifications when it comes to JavaScript and other interpreted languages. Developers shouldn’t even push code to the mainline without it passing syntax verifications.
One way to accomplish this is to use pre-commit hooks that prevent users from pushing their code when the linter verification indicates there are issues with the code.
Code Standards Adherence
Another vital type of check that linters provide is adherence to coding standards. Some people might dismiss this as a purely aesthetic concern, but they’d be wrong. Having a single consistent coding style is beneficial for decreasing the cognitive load of reading, understanding, and maintaining code. A codebase that has a consistent code style will be easier to understand, and the developers that use it will be less likely to introduce bugs.
That’s why there are linters that specialize in verifying codebases for adherence to code styles. Some tools are opinionated, i.e. they come with a pre-defined set of rules and conventions that can’t be changed. On the other hand, there are tools that can be highly configurable, allowing the user to adapt the tool to their preferred coding styles.
Potential Problems (a.k.a. Code Smells)
Code smells are signs that something might be wrong with your code. It’s amazingly useful to have a tool to detect those signs automatically, so you can investigate them further, if necessary.
For instance, many developers consider long functions to be a code smell. So, you could configure your linter to detect functions that are longer than a given number of lines.
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.
Linting can help with the heterogeneous knowledge on a team. For juniors, a linter is like an invisible senior team member that points out style guideline documentation, causes them to pause and question steps, and ultimately helps learn a new language. For seniors, it is an easy way to enforce, not their style, but the use of a consistent style on a team. Leading by example becomes more visible and somewhat built in. It saves many shoulder taps and time during code reviews.
The process of linting can be time consuming when starting out a project; it requires the discipline to catch linter messages from your first line of code. It is, however, worth taking advantage of the ways to customize. Make use of best practices.
