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.
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.
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 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.
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.
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.
Ruby's Rubocop and Brakeman
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.
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
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)
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.