Repository files navigation

No decisions to make, no.jshintrc or.jscs files to manage. It just works.

npm install standard

• 2 spaces for indentation
• Single quotes for strings
  • Except to avoid escaping like"in this lil' string"
• Unix line breaks (LF)
• No unused variables (this one catchesso many bugs and typos!)
• No semicolons
  • It's totallyfine.Really!
• Never start a line with( or[
  • This is theonly gotcha with omitting semicolons –automatically checked for you!
  • Always prefix with; like this;[1, 2, 3].join(' ')
• Spaces after keywords
  • if (condition) { ... }
• Spaces before/after function definitions
  • function name (arg1, arg2) { ... }
• Always name the context variableself
  • var self = this
  • Checks for accidental use ofwindow.self whenvar self = this is omitted
• Always use=== instead of==
  • obj == null is allowed for succinctness (obj === null || obj === undefined)

To get a better idea, take a look ata sample file writtenin JavaScript Standard Style.

The easiest way to use JavaScript Standard Style to check your code is to install itglobally as a Node command line program. To do so, simply run the following command inyour terminal (flag-g installsstandard globally on your system, omit it if you wantto install in the current working directory):

npm install standard -g

After you've done that you should be able to use thestandard program. The simplest usecase would be checking the style of all JavaScript files in the current working directory:

$ standardError: Code style check failed:  lib/torrent.js:950:11: Expected '===' and instead saw '=='.

1. Add it topackage.json

{"name":"my-cool-package","devDependencies": {"standard":"*"  },"scripts": {"test":"standard && node my-normal-tests.js"  }}

2. Check style automatically when you runnpm test

$ npm testError: Code style check failed:  lib/torrent.js:950:11: Expected '===' and instead saw '=='.

3. Never give style feedback on a pull request again!

The beauty of JavaScript Standard Style is that it's simple. No one wants to maintainmultiple hundred-line.jshintrc and.jscs for every module/project they maintain.Enough of this madness!

This module saves you time in two ways:

• No configuration. Just drop it in. The easiest way to enforce consistent style inyour module/project.
• Catch style errors before they're submitted in PRs. Saves precious code review timeby eliminating back-and-forth between maintainer and contributor.

The pathsnode_modules/,.git/,*.min.js, andbundle.js are automatically excludedwhen looking for.js files to style check.

Sometimes you need to ignore additional folders or specific minfied files. To do that, addastandard.ignore property topackage.json:

"standard": {"ignore": ["**/out/**","**/lib/select2/**","**/lib/ckeditor/**"  ]}

In rare cases, you'll need to break a rule and hide the warning generated bystandard.

JavaScript Standard Style usesjshint andjscs under-the-hood and you can hide their warnings as you normallywould if you used each linter directly.

To get verbose output (so you can find the particular rule name to ignore), run:

$ standard --verboseError: Code style check failed:  routes/error.js:20:36:'next' is defined but never used. (W098)  routes/submit.js:85:2: Expected indentation of 2 characters (validateIndentation)

The first warning isjshint (always starts with aW). You can hide it with a/* jshint -W098 */ comment. Re-enable with a/* jshint +W098 */ comment.

Example:

/* jshint -W098 */app.use(function(err,req,res,next){res.render('error',{err:err})})/* jshint +W098 */

The second warning is fromjscs (always a long camel-case string), which you can hidewith a// jscs:disable validateIndentation comment. Re-enable with a// jscs:enable validateIndentation comment.

No. Usejshint orjscs directly if you want that.

Pro tip: Just usestandard and move on. There are actual real problems that you couldspend your time solving :p

MIT. Copyright (c)Feross Aboukhadijeh.