Linters, is it a good thing to have?
Internshala is a recruitment cum training platform with millions of transactions getting processed every second. And when you have such a massive complex customer-centric platform, you don’t want to jolt users with bugs and flaws that may be catastrophic.
It becomes the massive responsibility of engineers to make sure that the system remains healthy. And in these conditions, engineers need to focus more on decision-making and learning things rather than tabs, spaces, double quotes, single quotes, or indentation. This is why it’s good to have linters as they take care of these things.
Bikeshedding, is when people fall into the trap of discussing something small and trivial around a more complicated project.
What is a Linter?
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 flags potential problems like syntax errors, and deviations from a prescribed coding style. They process and examine source code without compiling it into a binary.
In short, a linter is a tool to help you improve your code. Every linter relies on some coding standards.
Why use coding standards?
Setting a coding standard is very important in team development. Agreeing on one coding standard helps keep your code neat and easy to read and also makes it easy to see the difference in your code when reviewing them.
Here are several reasons why to use coding standards :
- Your peer programmers have to understand the code you produce. A coding standard acts as the blueprint for the team to decipher the code.
- Simplicity and clarity achieved by consistent coding save you from common mistakes.
- If you revise your code after some time then it becomes easy to understand that code.
There are other advantages also like enforcing a style, preventing indexing beyond the end of an array, catching mismatches in variable types, or finding possible memory leaks.
Linting tools for different languages:
One can add the following linting tools in the codebase for different languages:
PHP_CodeSniffer (PHP):
It is a set of two PHP scripts; the main phpcs script that tokenizes PHP files to detect violations of a defined coding standard, and a second phpcbf script to automatically correct coding standard violations.
ESLint (Javascript):
It is a tool for identifying and reporting patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.
Stylelint (Less/CSS):
Stylelint is the same as ESLint, but for style files. We have our design system at Internshala and don’t have to use absolute values for colors, typography, and spacing then why don’t add rules for it 😉.
So, every engineer at Internshala has the above tools configured in their IDE.
What if linters aren’t configured to the IDE and commits are made?
This is the beauty of linters and git hooks. Git hooks provide an additional check over the local development environment.
What is this?
Git allows you to fire off scripts on events in the git life cycle. You can do this by defining the scripts in event hooks. Take a look inside the .git/hooks directory of your git repo, and you’ll find many of the available hook samples. There are a lot of git hooks available but here we will talk about the pre-commit hook.
pre-commit hook
As the word tells “pre”-“commit” it let you execute code right before the commit. It is just a bash script, so whenever an engineer makes a new commit on the local repo, this pre-commit hook will run and validate all the linting rules defined for the codebase. And if any rule fails the script will return with a non-zero exit code. In that case, the engineer won’t be able to commit to the branch.
By this, every engineer knows that their git commit is validated with all the linting rules.
What if engineers forgot to configure the pre-commit hook on their local?
This is one more advantage of using git. If one does not comply with the nomenclature of using git pre hooks locally then we have GitHub Actions on the remote.
What is this?
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository or deploy merged pull requests to production. For more details: https://github.com/features/actions
For every linter we have created workflow file for github actions.
How does it work?
Whenever a new PR is created against the base branch and the reviewer is tagged for code review. These actions will run for the files that have changed.
As shown above, this PR has changes in LESS, PHP, and JS files so all the GitHub actions ran and checked the linter rules defined in the codebase. As shown, Stylelint failed (❌) and other linters passed successfully, which means LESS changes in this PR have some errors. By clicking the details one can get to know the detailed view of the action.
Conclusion
After all these things, our codebase is fully maintained and cleaned. :) At Internshala we care about code quality. I hope you do too.
