The 3 Levels of Code Consistency

Published on October 16, 2017 (↻ September 20, 2023), filed under Development (RSS feed for all categories).

This article first appeared at CSS-Tricks.

When working on an article about user-centered web development I ended up exploring a bit more the topic of consistency in code. Consistency is a factor for code quality and one of the key reasons why we need coding guidelines. Interestingly enough, I found, there are three levels of consistency: individual, collective, and institutional.

Level 1: Individual Consistency

At a basic level, when there’s little standardization in our organization (or when we simply work alone), consistency just means to be consistent with ourselves. We benefit from always formatting code the same way.

If we, just the one of us each, usually omit unneeded quotes around attribute values (absolutely valid, as such projects prove), we should always do so. If we prefer not to end the last declaration in a CSS rule with a semicolon, we should not do so. If we prefer to always use tabs, we should always do so.

Level 2: Collective Consistency

At the next level, and here we assume there to be code from other developers or third parties, consistency means to follow the code style used wherever we touch code. We should respect and stay consistent with the code style prevalent in the files we touch.

When we help our colleague launch a site and tweak their CSS, we format the code the way they did. When we tweak some core files of our content management systems (if that was so advisable), we do what they do. When we write a new plugin for something, we do it the way other plugins are written.

Level 3: Institutional Consistency

Finally, normally a level reached in bigger organizations, consistency means adhering to (or first creating) the organization’s coding guidelines and style guides. If the guidelines are well-established and well-enforced, this type of consistency offers the most power to also effect changes in behavior—individual consistency offers almost no incentive for that, collective consistency only temporarily.

When we normally indent with spaces and the corp style guide says tabs, we use tabs. When our colleagues launch their mini-project and, when helping out, we discover their code not to be compliant with the corporate guidelines, we take the time to refactor it. When we start something new, perhaps based on some different language, we kick off a guideline setup and standardization process.

❧ These three consistency levels are not mutually exclusive.

In our own affairs, we should at least strive for level 1, but personally I’ve made great experience hooking myself up to some external level 3 standard (I’m following Google’s HTML/CSS guidelines with the only exception of using tabs instead of spaces) and defining, in detail, some complementary level 1-style standard (as with a predefined selector order).

Whenever we deal with other developers, but only if there’s lack of a wider standard, we should at least aim for level 2 consistency, that is, respect their code. We touch something in their domain, we write it like they would do.

When we are in a bigger organization—though “bigger” can truly start at two people—this same idea of level 2 consistency prevails, but we can now think of setting up standards to operate at level 3. There, we can even marry the two levels: Follow the coding guidelines, but when we touch something that violates the guidelines and we don’t have the time to re-format it, we follow the style dominant in that code.

From my experience, being aware of these levels alone helps a great deal writing more consistent, and with that quite better code.

If you like to learn more about coding standards and like a short, very short read about them, check out The Little Book of HTML/CSS Coding Guidelines (updated).

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)