When you are starting out as a programmer you are happy for every bit of success, no matter how small. The least thing on your mind is writing pretty code, all that counts is functionality. Quick results. Sometimes advanced programmers find themselves in a similar situation. During a hackathon or when customers pressure you into impossible deadlines, style is the least of your worries.
Unfortunately neglecting good and clean style can quickly come bite you in the behind. To avoid dumb mistakes and make projects scalable in the first place, you should introduce proper style early on in your development life.
Look at your code
Before you continue take a good look at some of the code you have written today. Now consider these two:
- Is your code consistent and self-explanatory? Would other developers be able to quickly grasp what you’re doing?
Linting is the process of examining your code and identifying syntax errors and style anomalies (also known as static code analysis).
It has 22 documented options that you can use to customize its reporting behavior.
A bit younger, improved adaptation to your own rules – that is JSHint. It is probably the most used linter in the JS community. Everytime you find a github repo with a
.jshintrc file you know they care about linting. Files and directories that should be excluded from linting are mentioned in
With 69 documented rules it is more customizable than JSLint.
At 100 documented rules pretty much any style guide can be matched, just put them inside
.jscsrc and the linter will automatically pick them up. It also contains an option to exclude files.
The new kid on the block is ESLint. It is pluggable and can easily be extended. It combines the power of JSHint and JSCS and even though it is not as mature as those two it is ready for serious action and sports 169 documented rules that can be extended quite easily by plugins or own rules. It differentiates between warnings and erroOut of the linters presented here ESLint is the only one that will tell you which rules have been violated in the reporting process, making it the easiest to work with in my opinion.
All configuration can be done using
Performing a static code analysis
In order to install any of the linters you need to use
npm and install them as regular modules:
$ npm install -g jslint $ npm install -g jshint $ npm install -g jscs $ npm install -g eslint
Command line linting
You can now invoke analysis from the command line by calling the linter with the file or directory name of the code to inspect.
To analyze all files in the current working directory using ESLint issue:
$ eslint .
That will output a list of all found problems.
Personally I do not find this command line reporting to be terribly helpful, as I need to go back to my editor and look for the files and lines to fix them. Fortunately there is a better way.
Linting in the editor
Most editors have plugins that allow you to use these linters during the editing process instead. Be it Sublime, Atom, or any of the IntelliJ editors, all support linting tool messages inside the editing workflow, which greatly increases productivity.
Worry less about fixing style issues
In an ideal world, editors should make it simple to write code in style and hard to violate rules. This is when some of the fixers enter the stage.
When working in a team or you are switching machines or even editors often you want all their settings to be the same. Editorconfig is a small but very versatile tool that can set 6 common options via an
.editorconfig file. Once you have a configuration file and the editor plugin installed, everything works automatically.
.jsbeautifyrc config file. Beautification will not happen automatically, but usually it is initiated by pressing a key-combination (or selecting a menu entry). This affects either a selection, a whole file, or even the entire project.
For a more powerful beautifier take a look at esformatter. It comes with a whooping 286 documented settings and can bring your code into good enough shape to pass any of the linting tests, regardles how careless you code. In Atom it becomes a bit more complicated to use since you need to bring up the Command Palette and enter
esformatter for it to perform its magic.
Installing them is again done via
Bottom line of linting
As you see there are many tools available to support writing clean, stylish code. It needn’t be all complicated, even beginners can greatly benefit from a little effort on style.
To get started I suggest the following:
- Install ESLint and use the minimum set of rules
- Install Editorconfig and JS-Beautify to automate formatting as much as possible
- Get used to performing lints within your editing workflow – don’t use them as a quality check after you’re done
- Start with a small ruleset and introduce rules only as needed to avoid false positives. Nobody listens to a linter that reports thousands of violations
You can find my slides for a talk on this topic on slideshare and some sample code for Meteor projects on Github. This also contains documented and liberal rule configurations for jshint, jscs, and eslint.