the world of front end development is rapidly changing and with the popularity of node.js, it seems that javascript is creeping up everywhere. one of the misconceptions about javascript is that it is a hacky language by nature and the code is always going to look hacky. another popular misconception is that because javascript is executed in the browser and best practice is to minify your javascript code, it doesn’t matter about maintaining a consistent style within your javascript. sadly, many front end developers believe this and it is these same front end developers who are now experimenting with node.js and writing crappy server side code.
the really sad thing here is that there are amazing tools available that solves this problem. as far as i’m concerned it is a solved problem, the barrier to adoption is very low, and there is no reason not to have style adherence in your code base. what i’m talking about here are static code analysis tools for javascript. these are tools that will analyze your code and tell you where there are potential code smells.
there are two that i use for javascript development: jshint and the google closure linter.
two seems like it may be a little overkill and though both tools do have some amount of overlap, they serve two different purposes for me.
jshint
for me, i use jshint to detect errors and potential problems in my code. i prefer jshint over jslint because it is a little less opinionated (or can be configured to be less opinionated) than jslint. jshint is a good tool to find problems in your code, but it also helps with writing code with best practices.
google closure linter
google closure linter does the same things jshint does, but it also enforce style conventions. this is amazing by itself, but google has gone one step further and they bundled a tool called fixjsstyle with their gjslint app. fixjsstyle will try to fix all of the problems that gjslint finds. this blew my mind. this tool makes style adherence insanely easy. there is no longer any excuse not to conform to the same style…and yes, it is google’s style convention, but i happen to agree with most of what they say.
so great, there are two tools that lints your code for you, but wait, there’s more!
it seems that javascript developers are all gravitating towards using sublime text editor as their IDE. there are two plugins that will lint your code in real-time so that you will never have to run your linters outside of your text editor: SublimeLinter and JSHint Gutter.
so how do you go about doing it? if you’re on a mac/linux system, you do:
Install jshint and create soft link
|
1 2 3 |
npm install -g jshint cd /usr/bin sudo ln -s /usr/local/bin/jshint |
Install gjslint and create soft link
|
1 2 3 |
sudo easy_install http://closure-linter.googlecode.com/files/closure_linter-latest.tar.gz cd /usr/bin sudo ln -s /usr/local/bin/gjslint |
Install Sublimt JSHint Gutter plugin
In Sublime Text: Command-Shift P, Package Control: Install Package
JSHint Gutter
You can optionally configure Sublime to lint on edit or save: https://github.com/victorporof/Sublime-JSHint#automatically-linting-on-edit-or-save
Install SublimeLinter
In Sublime Text: Command-Shift P, Package Control: Install Package
SublimeLinter
Configure SublimeLinter to use Google Closure Linter
Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – Default
Copy the entire file that has been opened here
Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – User
Paste contents into this file
Make the following edits:
“sublimelinter_gutter_marks”: true,
“sublimelinter_mark_style”: “none”,
“javascript_linter”: “gjslint”,
“gjslint_options”: [],
“gjslint_ignore”:
[
110, // line too long
220 // jsdoc supression
]
It’s too bad you didn’t run a linter on this uncapitalized article.