Photo by Markus Spiske on Unsplash

Linters — unleashing the power of Static Code Analysis

Linter is a tool that analyzes source code. In other words, linters a code that uses static code analysis to run multiple verifications through different pieces of code. For more information on the concept, you can read in our blog what a linter is and how it impacts code quality.

In practice, the usage of linters in the development flow also mayprevent and reduce technical debts. However, as a common practice of the modern software development process,technical debts can be classified into desirable technical debt and undesirable technical debt.

The adoption of linters benefits multiple steps of the software development flow. It's not a tool meant to help engineers during the development. The most common approaches for linting is by running in a terminal, or by IDE integration.

The pylint, for instance, can be run in any terminal through pylint file_name.py. Besides, pylint integrates with lots of IDEs. On the other hand, taking the example ofsonarlint, a linter provided by the folks from SonarCube, only integrates with Eclipse, IntelliJ, Visual Studio, and VS Code.

Increasingly, Software Developers or Engineers agree that running linters before committing in git is a good practice, although it's not enough. The whole development chain needs to adopt the practice.

It's because linters depend on conventions among teams and the standardization of configuration files. For instance, configuring eslint can be very difficult. And as developers can run locally on their machines, the settings may mismatch, which would make its use pointless, at least to keep a code convention or style guide.

To solve this problem, many teams adhered to using linters during Code Review. It's a best practice that makes the issues found by linters explicit in Pull Requests. It's been so widely adopted that already got a name: automated code review.

Some teams are serious about code quality, and that's why they integrate linters with CI/CD Pipelines. The pipeline job is to check the found issues with customized scripts.

If the number and criticality of the problems meet the agreed standards, the changes can move on in the pipeline. Otherwise, the pipeline step breaks, and developers need to fix them before pushing the changes forward.

Below, there's a list of popular linters and the programming languages they can analyze.

Photo by Paul Esch-Laurent on Unsplash

JavaScript's ESLint and TSLint

As stated in the official website: TSLint is an extensible static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors. It is widely supported across modern editors & build systems and can be customized with your own lint rules, configurations, and formatters.

TypeScript is a subset of JavaScript that compiles to JavaScript. It's a different approach for using regular JavaScript, but with enhanced syntax, which may improve developers' productivity and reduce bugs.

In 2019, TSLint was deprecated. Palantir, the company behind the linter, announced that it would be more beneficial to redirect efforts converge both tools: TSLint and ESLint.

The ESLint statically analyzes JavaScript code to find problems. Similarly to TSLint, ESLint's design focuses on making the developer's life easier.

The primary maintainers are folks from the OpenJS Foundation. However, it has a vast list of contributors that use and develop the tool. Like any other open-source project, anyone can access its codebase.

You can learn how to setup ESLint and Prettier on Node.js in our blog.

Photo by Chris Ried on Unsplash

Python's pylint and flake8

According to the project's README.md, Pylint is a Python static code analysis tool that looks for programming errors, helps enforce a coding standard, sniffs for code smells, and offers simple refactoring suggestions.

It's one of the most popular linting tools for python. And all the rules are highly configurable and customizable.

You can install the linter by running pip install pylint, and if you need to troubleshoot or install from the source code, you can follow pylint's installation guide.

A compelling linter capability is that it ships with other executables that provide additional features, like pyreverse, a command that generates UML Diagrams for python code.

Another tool hugely adopted by python developers and community isflake8. It is a wrapper that runs pep8pyflakes, and mccabe under the hood. It's very straightforward and fast.

According to this Reddit thread, pylint and flake8 are very useful and primarily adopted. Many open-source teams prefer flake8, but many commenters suggest using both pylint and flake8 in a complementary approach.

As related, it seems to be a good practice to use flake8, which allows fewer customizations, to move into a more community maintained standard. Pylint, as stated, is very configurable. So it suits companies with lots of heterogeneous repositories because it can better adapt to each project standard.

Nonetheless, independently which linter your team decides to use, it's fundamental to automate code review and Continuous Integration pipelines with it.

Credo, an Elixir linter

René Föhring, the author of credo, defines it as a static code analysis tool for the Elixir language with a focus on code consistency and teaching


Differently than other languages, Elixir's credo is complete. It shows refactoring opportunities, looks for complex code fragments, fragments, and coding style mismatches. Installation and usage are straightforward. It uses the mix command, which ships with Elixir and efficiently manages dependencies, among other capabilities.

Following theproject's README.md, after adding credo as a dependency to the mix.exs file, you just need to run mix deps.get && credo.

If you're unsure about using credo, the Elixir Forum has helpful threads that may help you make your mind.

Photo by Kelly Sikkema on Unsplash

Ruby's Rubocop and Brakeman

Rubocop is a static code analyzer and code formatter. The Rubocop's default settings reflect the Ruby Style Guide maintained by the community. However, the configurations are very flexible.

The author and head maintainer of the project is Bozhidar Batsov. However, the list of contributors is much longer. The Rubocop's repository is highly active, and they release new versions very often, and the CHANGELOG.md file proves it.

It's pretty straightforward to install and run. Rubocop is packed as a gem, and its installation is as easy as gem install rubocop. The command cd project_path/ && rubocop runs the linter and outputs the result.

In the Rubocop's universe, each cop has the responsibility to detect a kind of code offense. There are several cops available. However, you can write a custom cop if needed.

Similarly, Brakeman is also a static code analyzer and focus on Ruby. Brakeman looks for security vulnerabilities in Ruby on Rails, a Ruby framework that easies web application development.

The README.md file contains instructions on how to set up and use Brakeman. As it catches many possible bugs, it's crucial to run it along with Rubocop for a comprehensive scan. However, it can find false positives, like any other security tool. In the introduction page of its documentation, you can learn more about advanced features, advantages, and limitations.

Golang linters — Gofmt, golint, and govet

Go is an open-source programming language in which the number of adopters increased in the latest years. It has lots of built-in commands that work like linters. The three most popular linters are gofmt, golint, and govet.

Gofmt formats Go programs to keep style consistency among files. In other words, it changes the source files to match the related style. On the other hand, golint performs similar checks. However, it only outputs the found mismatches.

Both linters combined work very smoothly. However, they only use static code analysis to look for standardization. They don't point to code smells, security issues, or any other category of potential bugs.

If you want a linter that checks the software's correctness, you need govet. The focus of govet is to find potential bugs or errors that would fail at compilation or execution time.

Swiftlint and SwiftFormat — popular linters for Swift

Swift is a programming language for building iOS apps. Nowadays, there are two popular linters for the Swift language: Swiftlint and SwiftFormat.

Swiftlint is an open-source tool that enforces styles and conventions for the language. It implements more than 70 rules and integrates perfectly with Xcode through a plugin.

SwiftFormat is another alternative for linting Swift code. It also has lots of rules. However, the default settings vary between the two linters. The implementations focus on matching the Swift community's style guide. Still, both linters are configurable according to the project's needs.

If you're stuck in the SwiftLint vs. SwiftFormat discussion, you can read NSHipster's post. It includes a third linter, swift-linter, which appears in the google fork of the language's repository. As the mentioned linter is not very popular, this article omitted the reference.

PHP Code Sniffer (phpcs) & PHP Mass Detector (phpmd)

PHP Code Sniffer is a set of two linters. The phpcs looks for violations of code standards in PHP, JavaScript, and CSS files. The phpcbf is a script that automatically corrects the violations found by phpcs.

According to the license file, the project in GitHub is under the Squiz Labs organization, which also holds the copyrights. Installation and usage are simple. However, there are multiple ways of achieving them, so refer to the README.md file for more information.

PHP Mass Detector is a linter that scans PHP source code and looks for potential problems such as possible bugs, dead code, suboptimal code, and overcomplicated expressions. It doesn't look for code standards violations like PHP Code Sniffer.

You probably want to run both, as they are not complimentary. phpcs and phpmd perform different jobs, and both are crucial for modern software development. If you need metrics, try the pdepend linter.

Kotlin's Ktlint and detekt

Kotlin, the programming language, has a built-in linter. However, the documentation is weak, and enthusiasts of the Kotlin language prefer other tools. That said, great alternatives are ktlint and detekt, as they're the most known linters in the Kotlin community.

The focus of ktlint is simplicity. It doesn't allow many tweaks, as it follows community guidelines. The following excerpt is from ktlint's FAQ: By using ktlint, you put the importance of code clarity and community conventions over personal preferences.

However, it's essential to have in mind that low configuration doesn't mean necessary "no extensibility." Ktlint supports custom rulesets and checks.

Detekt, on the other, is very configurable. It even has a SonarQube plugin. If you're unsure what to choose, consider reading an article from our blog on ktlint vs. detekt. For a better description of how to use it, you can check a step by step ktlint installation and setup guide.