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.
This short series will cover:
Why does code consistency matter?
Tools to keep code in order:
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.
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.
--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:
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 quessing 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 (
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!