Human beings are very bad at spotting missing commas or following code style guides. Read on to meet Emberocop, your new code guard.

Programmers are lazier than other people. They’d rather write neuron network to help you choose the shortest path in a supermarket than wander around it. The same idea applies to quality assurance or reviewing code. There’s no point in adding a comment ‘cut empty line’ for a hundredth time as the commiter will do the same change next time… Do yourself a favour and employ an Emberocop1.

Please note that the series isn’t limited to Ember.js; Tools like JSHint, JSCS can be installed as node packages and used in your favourite package builder.

This short series will cover:

  1. Why does code consistency matter?
  2. Tools to keep code in order:
  3. JSCS
  5. Code coverage
  6. Cyclometric measurement
  7. Using tools in an editor level
  8. What to avoid when introducing tools?

Why does code consistency matter?

  • Consistent style is easier to maintain across the team
  • Simple code is easy to scan and grasp
  • Debugging can be easier

Imagine that you crafted perfect code. It’s easy to understand, it’s consistent and with linters and a code style, you’re sure that you won’t spend hours on tracking bugs (‘aha! the missing semicolon!’).

Now imagine the same perfect code in a perfect app, but without a code style and static code analyzers. It’s still perfect as you’re the only developer, so you don’t have to worry about, but…

…one day you woke up and found out that the code you were emotionally attached to has to be shared among 8 other team members2. Some of them use Vim, some RubyMine, Atom, TextEdit, Nano, mcedit or any editor you can think of. Without any rules, you will be in trouble…

Consistent style is easier to maintain across the team

Your code should look like as it were written by a single developer, the one described above that had everything in order. Would you, the developer, attached to the code, allow yourself to damage the perfect structure? Nope.

Don’t do unto others what you don’t want others to do unto you.
― Confucius

Some rules has to be set and they have to be explicit. No matter what style you choose (single or double quotes), you have to stick to them. Without them your code style will start to smell.

If you didn’t set any rules yet, use JSCS — JavaScript Code Style. With --fix flag, you can fix almost all inconsistencies quickly. To prevent from merging bad code into master consider adding a script in package.json to run as a part of nmp test command like:

"scripts": {
  "jscs": "jscs -e app/ && jscs -e tests/",
  "test": "npm run jscs && npm run jshint && npm run…"

After that adding a comment ‘missing comma’ while doing code review will became a thing of the past.

Simple code is easy to scan and grasp

Keep it Simple, Sir! (KISS) pays off. If your code adheres to rules like:

  • Keeping line length up to 80 characters (columns)
  • Keeping methods short (up to 10 lines, avoiding indentation pyramids)
  • Keeping methods and variables names short and descriptive

it is not only clean, but also scannable and comprehensible without guessing and analyzing what the code does.

I didn’t think before that code typography matter, but realized that it can complement environment setup:

  • Dark / light theme colors decreasing eye fatigue
  • Legible fixed-size font (O vs. 0)
  • Bias lighting, f.lux, etc.

This will allow, I hope, developers to be productive and keep the flow for long hours. Don’t forget the fact that human brain working memory (short-term memory) has limited capacity for remembering things and lots of data can affect your performance.

Debugging can be easier

The side effect of consistent code and good having habits (writing in a way that you don’t need hints from a liting tools) are:

  • Easier and faster debugging
  • Lower cost for adding new features

Every time you make a change in a file under ember-cli setup, a rebuild process starts. When ember test is scoped to a single unit test, the feedback loop is shorter and you can get instantaneous results. For regular development, forgetting about simple things as adding a comma or a semicolon, lengthen the development process. It is hard to remember all those syntax peculiarities, but fortunately you can add linting tools in an editor level, which I’ll also cover in the series


Consistency should empower your team, thus it’s better to propose over enforce. You and your team will also benefit from introducing new tools step by step, otherwise it may turn out that innocent pre-commit can become a burden that slows down the development process.

What’s your experience? If I missed some point, let me know, so that the next part can be better!

Special thanks for Szymon Kieloch and Michał Czyż for feedback to this article!


Terrible JavaScript Mistakes To Avoid With A Static Code Analyzer

  1. Like Rubocop ;)

  2. 9 developers can deliver a project in 1 month, right?