We will retrieve one file from the previous OpenLayers library Version 2.12.
For this, download the file Map.js from https://raw.github.com/openlayers/openlayers/release-2.12/lib/OpenLayers/Map.js.
Type the following command:
gjslint Map.js
You will get 605 errors with messages like below:
----- FILE : /home/thomas/Map.js ----- Line 1, E:0001: Extra space at end of line Line 7, E:0200: Invalid JsDoc tag: requires Line 266, E:0131: Single-quoted string preferred over double-quoted string. Line 982, E:0120: Binary operator should go on previous line "+" Line 1106, E:0002: Missing space before "(" Line 1131, E:0002: Missing space after "function" Line 1089, E:0110: Line too long (83 characters). Found 605 errors, including 0 new errors, in 1 files (0 files OK).
Some of the errors reported by GJsLint may be auto-fixable using the fixjsstyle script. Please double-check any changes it makes and report any bugs. The script can be run by executing:
fixjsstyle Map.js
So now, make a copy of the Map.js file to save it in an eventual case where the fixer would suffer from a bug. Then, execute the following recommended line:
fixjsstyle Map.js
You will see:
fixjsstyle Map.js Fixed 582 errors in /home/thomas/Map.js WARNING: Line 1089 of /home/thomas/Map.js is now longer than 80 characters.
Relaunch the gjslint again:
gjslint Map.js
You now have only 23 errors. Really good compared to the previous 605 errors. You can ignore, in this case, errors like:
E:0200: Invalid JsDoc tag: This requires OpenLayers 2 code; do not use Closure so requires tag is not available
E:0110: Line too long (n characters): Sometimes, you need more than 80 lines in your code so ignore it, in particular for an existing code like the one used
Be aware, that you can use options to comply more or less to the language but can't customize everything. You are also encouraged to play with the options. To discover them, execute the following command:
gjslint -–help
For example, try the --strict options that check also your file indentation and you get 1867 errors or use the recursive option -r to apply check on a every JavaScript files in a directory.
We use a practical approach, but to understand the adopted code style, we invite you to go to the Google JavaScript Guide at http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml, in particular, if you don't want to fix all your code at the end of your project.
We gave you some information about the raw use of the Linter, but like for other cases, you already can check your code in the default OpenLayers development environment. Just launch ./build.py lint or build.cmd lint, depending on your OS.
Although syntax and styles are considered as good practices. Good practices are not rules; you choose to respect them more or less. Never forget that consistency is important, particularly when you need to share your code with other people. We reviewed how to do it with Closure Linter but this is not the only way. Let's broaden your vision.
It is always easier to use the same tools for all your JavaScript, but we advise that you be curious about other JavaScript coding styles for improving your knowledge and choose the coding style that fits you.
We recommend that you not only look at https://github.com/rwldrn/idiomatic.js but also at big library projects.
For example, check out the following links:
jQuery Core Style Guide: http://contribute.jquery.org/style-guide/js/
MoTools: https://github.com/mootools/mootools-core/wiki/Syntax-and-Coding-Style-Conventions
Dojo Toolkit Style Guide: http://dojotoolkit.org/community/styleGuide
To enforce your own coding style and share it, the most valuables tools are as follows:
jsHint: http://www.jshint.com
JsLint: http://www.jslint.com
Although those tools are interesting, the errors you receive when using them on your files are not always clear. So, we advise that you look at http://jslinterrors.com.