The more people who open a window, the more fingerprints that are left behind. Coding in a team is largely the same. Like a fingerprint, each developer has their own unique style that can look vastly different than others. Although there are linting libraries that will catch some of these style discrepancies, it can be difficult to enforce the nitty details. If you can make a piece of code look like it was written by one person, it immediately becomes clearer and easier to read (assuming the developer can write clean code in the first place, but I digress).

JSCS is a code style linter for programmatically enforcing your style guide. Ever get irritated when one developer doesn’t put a space between the ending function parenthesis and the opening curly brace? Here’s your chance to enforce this and create a strict, enforceable style for you and your team to follow.

Installation

JSCS can be installed via npm.

ZSH

1

npm install jscs-g

Setup

Let’s create a .jscsrc file at the root of your project. This will be used to define rules that you’d like to enforce in your JS codebase.

ZSH

1

vi.jscsrc

JavaScript

1

2

3

4

5

6

7

{

"disallowEmptyBlocks":true,

"disallowMultipleSpaces":true,

"maximumLineLength":120,

"requireDollarBeforejQueryAssignment":true,

"requireMultipleVarDecl":true

}

For simplicity, my .jscsrc file has just a few rule definitions. Here is the full list for your consideration in your project. The rules I have selected are:

disallowEmptyBlocks – Blocks must have code in them and cannot be empty

disallowMultipleSpaces – Disallows multiple indentation characters (tabs or spaces) between identifiers, keywords, and any other token

maximumLineLength – the max number of characters allowed on one line

requireDollarBeforeJQueryAssignment – requires that all variables assigned to jQuery objects be prefixed by dollar signs

requireMultipleVarDecl – Variables defined next to eachother should only be prefixed with one var declaration separated by commas

As you can see, having just a small subset of these rules can go a long way to writing consistent code in your project.

Running JSCS

After you have created your .jscsrc file, it’s time to run the style checker against your code. For the purposes of this tutorial, here’s a sample JS file that violates all of the rules above.

Create a new file (test.js)

test.js

JavaScript

1

2

3

4

5

6

7

8

9

varx=$('.test');

vary="tom";

if(x===0){

}else{

console.log("bad");

}

varz="two spaces";

Run the code style checker against it

ZSH

1

2

cd/path/to/your/project

jscs test.js

JSCS will output something like this:

ZSH

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

jQuery identifiers must start witha$at test.js:

1|varx=$('.test');

------------^

2|vary="tom";

3|

Vardeclarations should be joined at test.js:

1|varx=$('.test');

2|vary="tom";

--------^

3|

4|if(x===0){

Empty block found at test.js:

3|

4|if(x===0){

5|}else{

---------^

6|console.log("bad");

7|}

at most1spaces required between varandzat test.js:

7|}

8|

9|varz="two spaces";varx=$('.test');

-----------^

10|

11|

5code style errors found.

Bonus: Fixing the issues automatically

One of the coolest features of JSCS is the ability to automatically fix *some* of the linting errors it encounters (Currently whitespace rules, EOF rule, and validateIndentation). This is especially good if you’re incorporating this into an existing codebase.

The command is simple:

ZSH

1

jscs test.js--fix

Bonus 2: Parse ES6 code

It’s not perfect (yet), but it does a pretty good job of parsing against ES6 code as well.

ZSH

1

jscs test.js--esnext

Bonus 3: Create your own rules

Don’t see a rule that you’d like to enforce? Create it yourself! Here is the API.

This is just a brief intro to the power of this library. I will write a follow-up tutorial that will show you how to incorporate this into your workflow using Gulp and your IDE.