Programmers are smart…but not that smart. And, like any large group of people united by a body of knowledge, they fall into traps.
One trap in particular. Here’s how it goes:
1. Everybody has a common goal.
2. Somebody creates a way to reach the goal, and it catches on.
3. Over time, the masses conflate the means and the goal, and then they start aiming for the means instead of using the means to obtain the goal.
And then, in the name of following best practices, they write crummy code that would rather follow the rules than hit the goal.
Let’s look at an example: does this sound familiar?
“HTML defines the structure of your document, and CSS defines the look. If you mess that up, your code isn’t organized.”
This is the kind of thing people say—without caveat—and it is false.
We’ve forgotten, as programmers, that the goal isn’t to separate the structure from the look. The goal is to make the code easy to read and modify—for ourselves and for other programmers. Sometimes separating the structure from the look is helpful in reaching that goal. Sometimes, it’s not.
Suppose you were building, say, a code base to help print-only publishers with brochure-only websites easily move their businesses online.
What has to be customizable about a code base like that? Let’s look at the homepage to get an idea:
The colors, logo, copy, and magazine cover pictured on this page aren’t hard-coded: they’re just example branding to show a potential publisher how their site might look. But clearly, those are among the first things a company would want to change. And more than likely, the developer who wrote the code isn’t going to be the developer making the changes for them.
So, back to the goal: how do we make this code base easy for another developer to read and change?
I started with a few sass variables. So far, nothing sacrosanct:
All I’m doing is defining the colors so that another company could insert their colors easily, without figuring out which hex values equate to what in the code.
Then comes the part that raises some peoples’ hackles:
Check it out: this is CSS, but it’s modifying HTML classes called Light_color, medium_color, and dark_color.
That. Is. So. Wrong. HTML is supposed to be about the structure, dag-nabbit! In order for this to follow best practices, I would need to structurally define where each of those colors go.
But here’s the problem: a company doesn’t think about the color as a structural element.
When they want their colors inserted into the code, the developer can easily go in and put the appropriate hex values into the sass variables, and boom! The site looks more like home already. But maybe, just maybe, somebody at the company is going to want to apply their colors differently in some different places.
And when they do, they’re going to say to the developer “Hey, can you make XYZ this color?”
And we can make the developer do one of two things:
way #1: inspect the HTML, figure out the HTML tags on the thing whose color needs to be changed, go into the CSS, add the new color to the HTML tags in the CSS (or, if the other tags define other things that should not be the new color, make an all new HTML tag specifically to define the color…but OhGodHTMLisForStructureNotLook, so it has to have some esoteric name that isn’t the color even though that’s the whole point of the new tag)…
Whoa. Stop right there. We just used a convention to justify giving something a name that deliberately obfuscates its purpose.
When did that become OK? The answer is never. It’s not OK.
The HTML/CSS distinctions are a tool at our disposal to make code clearer. They serve clarity…clarity does not serve them. And if they can’t serve clarity in a situation like this…
Trash ’em.
At least for that particular element of the project.
So what is way#2 to change the color?
way#2: add the appropriate color tag in the HTML.
It breaks the rules. But when breaking the clarity rules is better for clarity than following them…
that’s the point at which the rules stop applying. Clearly.