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?
Consistency.
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
Bug Fixes
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.
Cleaner code
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.
For analysing our javascript we use JSHint.
JSHint is a fork of the original JSLint. Both are great choices that will improve your code, but JSLint is more like Douglas Crockford (the creator of JSLint) is peering over your shoulder and pointing out how you are destroying javascript with every keystroke…or maybe that’s just me.
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:
jshint test.js
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.
You can do it for all your javascript files in a project with an IDE, such as Intellij, which have great built-in code style plugins which can do static analysis on the fly. This saves time and gives the developer power to address code flaws immediately. No need to review all that code you toiled over and search for the instances, they are highlighted quickly (or as quickly as a bulky IDE can be).
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)
Textmate:JSHint.tmbundle
Brackets:Brackets JSHint
gEdit:gEdit JSHint
Vim:jshint2.vim
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.
{
“eqeqeq”: true,
“maxlen”: 100,
“indent”: 4,
“globals”: {
“jQuery”: true
}
}
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.
Additional languages:
We have focussed on javascript in this article but linters are available in any well known language.
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.
