Limitations of Linters—Is it Time to Level-Up?

Static code analyzers, seen by many as the evolution of classic linters, are code analysis suites that offer a broader scope and more in-depth capabilities than linters. In this piece, I attempt a high-level comparison of the two, while highlighting certain shortcomings of linters that can be solved through static code analyzers.

As developers, we have all used, or at the very least heard of the following two terms– 'linter' and 'static code analyzer'. Both linter and static code analyzers are often used to describe similar tools, and even used interchangeably. The service these tools offer is broadly similar – examining source code for potential issues. However, they are not the same thing. In fact, based on the program you go for, the code-checking services they provide can greatly differ. In this article, we take a high-level comparative look at these two tools, with examples of some Java-specific options.

What Are Linters? 

Linters or lints are a form of simplistic static code analysis tool that originated in the late 70s. A computer scientist called Stephen Johnson first used the word 'lint' to describe a program he came up with to help debug portability issues for a C-based program he was writing at the time. The idea took off from there and today is an all-encompassing term used to describe any basic program that can be used to examine source code and detect bugs and errors. The scope of a linter can range from picking up on code smells, identifying syntax errors, or in the spirit of its very first iteration, offer up compiler optimizations. 

What Are Static Code Analysers?

The phrase 'static code analyzers' can refer to linters, but in programming circles today it is eponymous with code analysis suites that offer a broader scope and more in-depth capabilities than linters. The hallmarks of these static code analysis suites include multi-function ecosystems, a comprehensive and easy-to-use user interface, a widespread of capabilities, and the ability to analyze code in a variety of languages as well. Static code analyzers are more advanced and comprehensive tools than linters and ones that offer a more interesting palette of code testing solutions. 

Limitations of Linters

Let's take a look at some limitations of linters that can be solved with static analyzers:

• Language Limitations: As established by the lists above, a multi-language approach isn't the norm for linters. In fact, most only support a single language. Static code analyzers offer rich pickings in terms of language support in comparison.
• Stages of Development: A linter is at its most effective when it is introduced right at the top of a programming venture. If you are midway or at the tail end of the development of your program, the use of the linter would be severely limited. A static code analysis tool, on the other hand, can be introduced to the coding process at any part of the development cycle and offer the same level of usability and value. 
• Functionalities: The scope of function is another area where these types of code analysis tools differ. The ambit of functionalities offered in linters is very narrow compared to those offered in static code analyzers. Linters typically only focus on one aspect of detecting issues within programs as opposed to the intricate and elaborate setups of static code analyzers. So you would need to run your program through multiple linters to detect issues across aspects that would typically all be covered within a single static code analyzer. 
• Complexities: Setting parameters and rules can help streamline the code-checking process and ensure that coding practices that don't fall between mainstream ruling parameters aren't erroneously flagged as issues. Linters are typically set against specific, widely-accepted rulesets and don't have much scope for the degree of customization and setting of parameters to circumvent this issue. 
• Low-level Flagging of Issues: The scope and depth of issues identified by linters are usually quite shallow. Since they are restricted to one issue type and comparatively simple programs, there is no aspect of nuance or context used to conduct a deep-dive on the code. This is not the case for static code analyzers though, as with the example we cited earlier, where modern technologies like AI are integrated into the platform. 
• Ease of Use: The user interface and navigation setup for a linter are quite basic and run-of-the-mill. Static code analyzers tend to offer a slicker and more sophisticated UI to help navigate the facets and functionalities packed within their fold. 

Static Code Analyser or Linters, Which Should You Choose?

Both linters and static code analyzers offer added value to coders and programmers. But which one you choose is entirely dependent on your needs and preferences. If you are developing a simple program with little or no commercial value, a free-to-use linter like the ones I have listed might be the way to go. However, if your needs are more complex or your tech stack has multiple languages, or if you or your company stand to gain commercially from the development of the program you are working on, a static code analysis tool could be the more sensible option. 

Examples of Java-specific Linters—

side-by-side summaries of some java faves—

• Checkstyle: If the name didn’t give it away, Checkstyle is a tool that helps you ensure that the code that you are writing fits within the parameters of a specific coding convention or standard. The two styles currently covered by Checkstyle are Google Java and Sun Code Conventions. 
• PMD: A source code analysis tool that offers more than just Java support, PMD is a well-known option among programmers. The features offered in PMD include the ability to identify unused variables, detect empty catch blocks, and highlight unnecessary object creations. You can also opt for a companion tool called CPD that helps you find duplicate code. 
• SpotBugs: SpotBugs started life as FindBugs in 2006, a tool to identify bugs in your code. A decade later, the FindBugs project was dead in the water, until it was resurrected in its current avatar as SpotBugs thanks to a community-driven effort, picking up right where FindBugs left off. 

Examples of Static Code Analyzers—

These are lesser-known but can be very useful—

• Veracode: Another popular static code analysis tool, Veracode has a narrower focus that is directed only towards security issues. This tool conducts code checks across the pipeline to detect security vulnerabilities and includes IDE scans, pipeline scans, and policy scans as part of its service. It also creates an assessment of the code for audit and compliance as part of the program. 
• Embold: A more comprehensive static code analysis platform, Embold offers support across four pillars – code issues, design issues, metrics analysis, and duplication. All of these features are available across multiple languages, including Java, C, C++, C#, Objective-C, TypeScript, JavaScript, Python, and PHP. If you are looking specifically at Java, Embold harnesses code checkers like PMD and SpotBugs as part of its ecology, and in total offers over 700 checks for this particular language alone. Embold offers free lifetime versions of its product.

• Coverity: An open-source software quality checker, Coverity was first started in conjunction with the US Department of Homeland Security. Today, this simple tool can be used to detect issues in projects written in Java, C/C++, C#, JavaScript, Ruby, or Python. Coverity is also compatible with some version control systems in the form of GitHub and Travis CI. 

Whether you choose linters or static analyzers, we hope you found this useful. Please comment if you would like to see a more detailed side-by-side comparison of results rendered by linters and static analyzers for some java-based programs.