Todd Wolfson

Software Engineer

February 06, 2015

Steep decline of style comments in PRs when `jscs` is introduced

The above graph is from an experience I had while leading a team at Uber. We added 2 new engineers from projects with different languages and styles. The first PR was good code but very inconsistent with the existing coding practices.

Instead of writing up a style guide and making the engineers memorize it, we added jscs to the project and instantly fixed everything. The engineer got quick feedback for style conflicts via the test suite and all future PR comments were focused on actual issues rather than style discrepencies.


There are 2 categories for linting/style checking tools: validators and formatters.

A validator scans through the code and points out issues. For example:

Extra comma following the final element of an array or object literal at Gruntfile.js :
    11 |      all: {
    12 |        files: {
    13 |          'dist/css/index.min.css': 'public/css/index.scss',
    14 |        },
    15 |        options: {

A formatter automatically adjusts the code. For example, it converts:

var hello = 'world',
    goodbye = 'moon';


var hello = 'world';
var goodbye = 'moon';


Validators have been around for much longer and as a result, have more features than formatters.


Most of these tools have options unique to themselves. As a result, it is becoming common to write wrappers to run multiple tools with predefined configurations:


Formatters are an emerging set of tools and as a result, have less features.

Top articles

Lessons of a startup engineer

Lessons from being a 3x first engineer, former Uber engineer, and working at even more startups

Develop faster

Removing the tedium from creating, developing, and publishing repos.

Sexy bash prompt

A bash prompt with colors, git statuses, and git branches.