It should be a coder’s goal to make sure that every character in every line of code serves some purpose.
The quality of code is not dependent on good form, prettiness, or theoretical benefits. Code should solve problems.
HTML5 lets you omit closing paragraph tags and closing tags for list items. Some cringe at the thought of this, but it’s perfectly valid code. So if omitting extra tags helps your code become leaner and faster, then you’re solving a problem and that makes it good code.
CSS classes are customarily written in all lowercase and with hyphens. Yes, this looks pretty, but does it solve a problem? Maybe it’s more readable. That would be fine. But what if a combination of camel casing, hyphens, and underscores can help the readability and future maintenance of the code? Then it’s good code, because it solves a problem.
For years many developers have preached about “clean HTML” and avoiding “classitis”, promoting this as a means to make documents more semantic. But in many cases, these semantics arguments have been theoretical at best. Yes, littering your HTML with extra classes might make your HTML a little bigger and slightly slower. But the miniscule loss in page speed and “good form” is gained tenfold in CSS maintenance and modularity.
Even a simple semi-colon left out of a line of JavaScript can seem so difficult for some to accept. But if its omission solves a problem (i.e. fewer characters) and it doesn’t have any other drawbacks, then it’s good code.
Theory and future-proofing has its benefits. Good code, however, is code that has a purpose.
Good code doesn’t just look pretty. Good code solves problems.
“Good code doesn’t just look pretty. Good code solves problems.”
Right!!!
I am retired renovation contractor who plays around with HTML javascript and CSS. It helps to keep me sharp? I think of developing as a puzzle. This is what I want it to andthis how I want it to, now how do I make it work.
I came across your site while looking for something else. I spent last night and this morning going back through your posts and the comments they generated. I was tired when I got to October 2009. I want to let you know how much I have enjoyed your posts.
My first computer was a MacPlus that I paid over $2000 for. I’ve had macs ever since. So of course I think Macs are best and I hate all things Microsoft. Thanks for an entertaining and very informative blog. You are my latest bookmark!
“Good” code is a difficult thing to define, because code has a lot of problems to solve (some of which might be mutually exclusive!). You write that “the quality of code is not dependent on good form, prettiness, or theoretical benefits. Code should solve problems.”
While theoretical benefits are debatable (they’re theoretical, after all :) ), isn’t maintainability a problem? If so, good form or “prettiness” may be solutions to a problem. You mention this in the fourth paragraph of your article: “… can help the readability and future maintenance of the code? Then it’s good code, because it solves a problem.”
Your fifth paragraph is interesting, though, because a conflict is introduced. If good code is performant and good code is maintainable, what happens if in making it more one, you make it less the other? How do we calculate the cost/benefit ratio to the different clients of our code?
And, in the case of the missing semicolon in JavaScript, the problem is that its omission did have a drawback!
I agree, (especially what you said about my 5th paragraph) and that was partially my point: That you have to weigh the options based on actual problem solving, not on what might happen in 5 years when (for example) browsers start addressing semantics in a better way.
As for your last statement, it depends who you ask. People who leave out semi-colons where Linting programs telling you to add them do not view it as a drawback. But I’d say that since it causes so much debate, I think we’d be better off just using the semi-colons and getting back to work. :)
Definitely! To me the problem isn’t the concept of “best practices,” the problem is that certain techniques or methods may have been elevated to the status of “best practice” without any actual demonstrable reason. Now how did that happen?
As for semicolons in JavaScript… uh-oh. I don’t want to open a can of worms here! :) But adding or removing semicolons simply because a linter says or doesn’t say to is part of the problem I think. The linter is a tool (and a useful tool at that!), but, as a developer, one should understand why a linter recommends this or that.
Is this a joke? Closing tags not only show you where the element ends, but also *which* element ends. They improve readability enormously.
And since the closing tag still exists whether you type it or not, there is no performance issue. In fact, pure XML can be processed more efficiently, because you don’t need to worry about inferring closing tags everywhere. Missing tag? Instafail.
Omitting them just because the browser can infer them is pure laziness, working on the assumption that nobody (not even you) will ever have to look at the mess you just wrote.
It’s also reason #563 why HTML5 sucks.