As my click-bait title suggests, I'm going to explore when the idea of writing consistent code can be harmful.
I've been reading a lot on blogs of the most renown tech leaders, and also in the tech mailing lists such as HTML5 Weekly, many occasions where the idea of consistency in conveyed as the most ideal of code styles.
In one case, the very influential blogger made a blanket statement, profound in its importance to the article, that all HTML element attributes must put the
class attribute first, followed by the
id then other attributes may follow. Other than the do's and dont's written in code, there was only one reasoning described in words, and i quote;
~ "The order follows what the most common attributes are. Almost every element will have class, most will have an id, some will have data attributes, etc. This makes it easier to mentally parse."
One does not simply say it is more common therefore it is best.
In terms of easier to mentally parse, if you had been writing, editing, refactoring, renaming, finding, replacing, ...repeat anything in HTML you would know (as well as you know your native spoken language) that all your
a tags have the
href first, followed by the optional
target, then any other attributes. If you don't immediately agree that is ok, I believe strongly that you already subconsciously know having written as much HMTL as i have, but I'll explain it here in case you have not.
But before that, let me introduce some other HTML tags so that you might come to the knowledge yourself. For an
src first makes sense, then the optional
alt, and then other attributes. I could go onto other elements that have similar unique attributes and make the same point;
input[name] though I sense through the ether of internet, time, and space; that you get the picture by now.
So all is left is the main thing; is why?
Not because the attribute is common like class or id, and not because it is logical either (event if it is :P), but the unique attribute for the elemetn should be first only because of the most important of reasons;
Readability: you identify immediately with the element and its purpose when you see;
<a href="/sub/content" target="_parent" class="bem-it__up" id="actionHook" data-other="stuff">More<a/>
Over something the article author had suggested;
<a class="bem-it__up" id="actionHook" href="/sub/content" target="_parent" data-other="stuff">More<a/>
It's effort to see what is happening in the second example, whereas the first is elegant in its simplicity to know what that element if for.
As a bonus, a novice developer can easily refactor any
href without regex, yet using regex also became straight-forward with example 1.
- Readability is better than consistency at the cost of identifiability
- Unique attributes are expected; expected is a form of being consistent
- Enabling the novice with a simple style; Simplicity is better than consistency at the cost of unproductivity.
So I ask anyone who blindly promotes consistency please do explain to yourself why, but simply questioning why would all elements in all cases benefit from the class and id attributes being first tells you very little, you need to question why not be consistent, what benefits would i lose by blindly choosing to be consistent.
If consistency is the only why, then perhaps in this case consistency is an anti-pattern for simple readable HTML and therefore you should be thinking about it's harmful outcomes instead.