I, for one, can’t stand that style. I’m heavily biased towards information-dense coding styles, which don’t have much whitespace. People mechanically argue “oh but whitespace is so important etc” as if we were designing a modern art installation. Well, whitespace is indeed essential, but you have to discriminate between a touch of elegant whitespacing for the sake of clarity, and “oh dear! My 80-column row seems to have just 12 characters on it. Come to think of it, every row on my 30-inch Cinema Display has 12 characters on it.” Seriously, I don’t know why anyone would use an 80-column terminal anymore, unless they enjoy coding on their iPhone. I tend to think 120 or 160 is ideal; any more than that and most people won’t be able to see the whole thing without moving their head. Anyway, I’ll be conservative and assume 80 columns. The average end column in the above code snippet is roughly 15, which means in your scrawny 1975 80-column terminal, you’re filling 20% of it with information and 80% with whitespace.

There’s an old figure that says the average programmer codes 10 lines per day. It’s obviously not a very accurate figure and maybe it was meant to include all the non-programmers on the project or something, but the point is interesting, as there’s probably some reasonably consistent LOC per developer figure (obligatory mutatis mutandis caveat). Seizing on this historical figure, Bruce Eckel said a while ago (paraphrasing) “if I only get 10 lines a day, I want them to be good ones”.

That’s why I favour information-dense coding styles. As a programmer, you’re supposed to be an expert user who spends all day in front of the same system. This is a typical example of a situation which demands a “Sovereign Posture”. It’s an expert system. When people long for glorious pastures of whitespace, they’re ignoring the fact that with sufficient practice, they’ll be virtually as proficient at reading and writing a more information-dense style, and vastly more efficient by having so much more code available at any time. It’s the same reason why Real Programmers commit to learning Unix and Vi or Emacs; if you’re going to spend decades working in this environment, why wouldn’t you spend a few days committing to the most efficient tools available?

For the record, I still have plenty of whitespace in my programs, but when there is a decision to be made between one popular convention and another, I almost always go for the one which reduces whitespace. I have enough faith in programmers’ pattern-detection skills to know that in time, they will be fine with either style, but the one with less whitespace will always give them more bang for their Cinema Display buck.

What I do is group similar attributes on each line. I’m pragmatic about the precise rules. If it’s just a handful of properties, I’ll stick them all on the same line. If there’s more than that, then typically I’ll have one line for appearance (colour, fonts, etc.), another for layout, and possibly more for other things like display settings or detailed positioning. You also don’t need whitespace between each rule either, so you can often end up with a whole sequence of related one-liner rules:

This format is not only denser but also easier to comprehend as related properties are grouped together. The typical one-line-per-property format tends to include a random jumble of properties; rarely does any thought go to the order in which the properties appear.

8 thoughts on CSS Coding Style and the Unbearable Tendency for People to Adore Whitespace in their Source Code

It’s ironic (or amusing 🙂 that this post is such a perfect example of one-property-per-line css beating the crap out of the others in overviewability, even if it’s when browsed on the web, here, rather than in the context of your editor.

It gives you better scanability and lets you quicker tell what padding is set for #score, for instance. (Whereas the batch-it-up-to-minimum-vertical-space gets you better overview of the next structural level, “which id:s, classes and rules do I have here?”)

I’m usually with you in the brevity camp, but CSS statements make sense not to clump up more than you would clump up code statements while programming. Sure, expressions can be long, and there are always cases where one-liners and if-then-else constructs do look nicer kept on a single line, but by default, one line per statement wins.

That also makes diffs in your version control of choice a lot more readable, for the very same reasons.

This is getting dangerously close to the “should open brackets be on the end of the line, or on a line to themselves” debate which is an argument that will never be won (the former is the correct way btw :-)).

Wrt CSS, I prefer one property per line and agree with Johan that it makes performing a diff between versions much easier. I do agree that combining properties into a single declaration where possible makes a lot of sense though. Also, all CSS should be minified for production builds.

I agree with Johan. There is plenty of cognitive and linguistic research that shows that, in terms of reading and comprehension, vertical scanning is easier on the eyes than rapid serpentine horizontal scanning, which can be fatiguing. When I read a long article or essay, I usually increase the font-size and make the window narrow, so as to increase the article’s “verticality.” I tend to read a lot faster that way.

I know that we’re dealing with code here, but the principle holds: it is easier to understand a program if lines remain short. 80 characters per line stopped being a technological barrier with the advent of graphic desktop environments and resizable terminals. It remains a cognitive barrier nonetheless.

Another benefit of sticking to one expression per line is that it lets coders refactor and move snippets around much more easily (quickly select a line and move at will, without having to worry about re-indenting).

I’m not that particular with CSS code-style, but I am with most other formalized programming languages. Once you break out of the one-expression-per-line convention (other than in standard cases, like for loops), you allow code to be a lot more freeform and less standardized.

@ecmanaut – Disagree on the comparison between clumping CSS vs clumping other languages. Typical CSS line goes to about 15-20 columns out, typical Java line goes to 40-120 columns out (there’s more nesting, so there’s a lot of whitespace on the left; names tend to be longer and include namespaces and hierarchies). I agree about diffs, though tools like IntelliJ are pretty smart about looking inside each line as well.

@tom – Well, my main point here is that the time-old debate hasn’t really been had in the world of CSS.

@shiran
It’s true there’s a limit on the usable width, which I mentioned too, I just think that 80 is “paving the cow paths” (accepting the de facto standard without questioning it) and 120-160 seems more appropriate on a big, hi-res, screen. In terms of refactoring, I refer back to my comments on Vim/Emacs. Most programmers use crappy editors and most programmers use one statement per line. The editing benefit from one statement per line is vastly dwarfed by the editing benefit from using Vim/Emacs. (There are bindings for Vim/Emacs in all the major IDEs.) While the particular task of refactoring may be slightly more efficient, you’re probably better equipped to locate refactoring opportunities when you can see 5 times as much code at once.
As far as consistency goes, I’ve seen some awful coding standards applied purely for the sake of running automated syntax checks and ensuring the team codes in the same way. Like the insane Java setter/getter convention that does in 9 lines what should be done in 2. As long as I’m working with people who also care about code quality and can agree on general principles, I’d rather live with some ambiguity than adopt a strict standard.

You must not write much CSS if you have never had to do one-rule-per-line… I like to group my rules on one line too, but I can’t do that if the line is going to be wider than my screen… that makes it less readable.

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff