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 one of the key reasons why we need coding guidelines and also a factor for code quality. Interestingly enough, so I noted, 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 simply 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 as is 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 never 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 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 reformat it, we follow the style prevalent 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, check out other CSS-Tricks posts about the topic, and if you like a short, very short read about them, perhaps also The Little Book of HTML/CSS Coding Guidelines.
I’d like to disagree with this if I can. I guess it’s debatable, but it seems like the first step towards forgetting/ignoring the standards completely.
My thoughts exactly. It takes the matter back to individual consistency, just not your own. But I’m rather non-conformist; I use tabs because 1 tab is more efficient than 4 spaces. Whether adding, deleting, or otherwise handling.
Yes. Yes. Yes.
That’s all I have to say on the matter.
At my company most UI projects are “owned” by a particular developer, and we’ve found that stage 2 works very well for us. We come from different backgrounds and have very different coding styles – not just in terms of formatting, but even in terms of patterns and libraries. After struggling to agree on a single style, we resolved to just letting the “owner” of a given project make those decisions about it, which has kept us all comfortable and consistent and off each other’s toes. That said, there are only three of us here and I doubt this practice would scale up very far.
I was hoping you’d have some data to backup these ideologies.. these ideas are prevalent throughout the engineering world, and they make sense, but has anybody ever done a study to defend the hypothesis that consistency yields quality?
We actually lose quite a bit of time adhering to style guides or obsessively formatting code, and may develop animosity when we clobber someone else’s authorship of a line of code simply to correct their style – do the benefits of consistency outweigh these negatives?
Are you using linters or tools like stylelint/stylefmt to enforce a code style? In modern dev environment code formatting is largely taken care of by linters and building tools.
@Jz, do I get you right that you wonder whether entropy/disorder would actually be such a problem after all?
I admit, there’s appeal to this, and we should probably study this, and yet from experience lack of guidelines (and thus lack of consistency) leads to much lost productivity because each time we look at other people’s code, we lose time orienting ourselves and understanding respective code. That loss, if we’re experienced or plain lucky, may be small, but we’ve probably also all spent an awful amount of time in someone else’s code solely because it was formatted differently. And that’s the empirical side suggesting that yes, order and consistency and guidelines are useful.
(I’d immediately write “quality” all over consistent code, too, but I see how that’s somewhat a different debate.)
CODE THAT WORKS is the only “best” code xD
Helpful may be to use .editorconfig files: