Last updated at Fri, 03 Nov 2017 19:52:26 GMT
As developers, we all strive for clean, readable, and easy to refactor code; but, unfortunately, this doesn’t always happen.
No matter how great a developer you are, or what language you’re coding in; problems caused by bugs inevitably spring up like weeds in the grass. These problems are exasperated by poorly organized and poorly written code. Once quality starts to drop, even the cleanest high-quality code in your project begins to be affected, until you’re left with a jumbled mess of (and hard to follow) code.
What is Static Code Analysis?
Also known as linting, static analysis is analyzing code without execution. A good example of static analysis is a compiler, which locates lexical and syntactic errors in the code.
Essentially, you write code and the static analyzer will point out errors.
Why is it important?
Developers have individual style when writing code and these tendencies can pass from different paradigms and other languages we write in. When working on a personal project (with only one developer) there is nothing wrong with personal style, but the moment we start collaborating, our differences will clash and inconsistencies will be created.
Consistency starts with minor things, like indentation or line length; and once the standards are decided can be enforced by the analyzing tools.
Some Colleagues may have disagreements over the style choices
Developers also spend lots of time fixing bugs. Most of these bugs are reported and then fixed, which means the bugs were impacting the software and creating a bad user experience. Ideally, these bugs would be caught during development and never go into production. Testing can help, but isn’t perfect since user behavior can be unpredictable.
Some best practices enforced by a linter will help reduce these errors.
Do you have unused parameters in a function or unused variables littered through your code? Maybe you thought you needed them, but then figured another way.
Either way you don’t need them, so why are they still there?
This clutter is making your code hard to read for another developer and eventually will leave you confused too. It’s time to get rid of them.
Enforces good habits
For less experienced developers, static code analyzers stop bad habits before they begin since they’re constantly reminded not to make the easy mistakes.
How do you use it?
We have a process of Continuous Deployment at Logentries, which integrates the use of code analysis into the build on the development side (check out how we use it). This process makes it easier to maintain code quality and find bugs BEFORE we go to production. This saves lots of headaches in the long run.
Either way I prefer JSHint because it is more flexible around the way YOUR teams way of doing things. It’s “A” standard but not necessarily “THE” standard, which JSLint claims to be.
Great, how do I set up JSHint?
You can install as an npm package using node:
npm install -g jshint
This will install it globally on your machine.
Then JSHint can be run from the command line:
This is okay if you want to check one file, but if you have a project with lots of files, this would get very tiresome.
To set JSHint up in Intellij:
- Open Settings
- type JSHint
- enable the code quality tool and configure options.
It’s simple to set up and now you can write your own .jshintrc. Very similar for Wordstorm and PyCharm.
Rather use a text editor instead?
SublimeText: SublimeLinter (Which supports lots of language)
But wait a second! You said it was configurable, I don’t want just the default.
Inside, the project will have a .jshintrc file that houses the rules to be enforced.
In the example above .jshintrc follows a JSON format, where each key is a different rule to either enforce, or not.
- “eqeqeq” doesn’t allow the use of == or !=, just === and !==. The rule is enforced because we have said this rule is true; a false would mean we aren’t interested in this rule.
- “globals” allows us to use variables defined outside the file we are checking.
- “maxlen” gives lines a maximum length, helping to keep the code readable without lots of scrolling.
- “indent” sets the number of spaces that and indent is allowed be.
Full documentation for all the possible rules that you can have JSHint analyze.
At Logentries we use:
Python – Pylint
Java – Sonarqube
Why should you use it?
Static code analysis can help your team produce consistently cleaner code with minimal long term effort. The hardest part is getting started and even that is painless. Once you’ve begun you will start to see the benefits immediately and never look back.