programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

Extreme Formatting

Not long after I wrote Solving the Wrong Problem, it occurred to me that this site is small because of what I decided to leave out, and that I never tried to optimize what remained. To that end I used a PNG reducer on the two images (one accompanies Accidental Innovation, the other is in The End is Near for Vertical Tab). And I ran the CSS through a web-based minifier.

A Cascading Style Sheet written in the common way looks like this:

blockquote {
    font-style: italic;
    margin-left: 1.25em
}
#top {
    background-color: #090974;
    color: #FFF;
    margin-bottom: .67em;
    border-color: #7373D9;
    border-style: none none solid;
    border-width: 12px;
    padding: 2em 0 0
}

and so on, usually for a couple of screenfuls, depending on the complexity. The minified version of the above has no extraneous spaces or tabs and is only two lines: one for each selector. But now I had introduced a workflow problem. I needed to keep around the nicely formatted original for easy editing, then re-minify it before uploading to the site. The first time I wanted to change the CSS it was a simple tweak, so rather than automate the conversion I went in and edited the minified version directly.

And I found that I preferred working with the crunched-down CSS.

Unless you're reading the newsfeed, the CSS file is already on your computer or phone, so take a moment to look at it. If you're sighing and shaking your head at this point, you could put each selector on a line by itself, but that adds another 23 lines. 23 more if each closing brace gets its own line. And another 40 or so to make sure there's a newline after each property. Somehow the raw 23-line version puts the overall simplicity of the stylesheet into clear perspective. Free of superficial structure, it takes less than half of a vertical window in my text editor. Is inflating that to over 100 lines--enough that I need to scroll to see them all--buying anything concrete, or is it that verticality is such an ingrained formatting convention?

Okay, right, there's also readability. Surely those run together properties are harder to scan visually? Syntax highlighting makes a big difference, and any editor with a "highlight all occurrences of a string" feature makes this layout amazing. I can see everywhere the border-style property is used all at once. No jumping to different parts of the document.

Here's a good question: Does this apply to real code and not just HTML stylesheets?

There's an infamous, single printed page of C code, written by Arthur Whitney one afternoon in 1989, which became the inspiration for the J language interpreter. It occasionally gets rediscovered and held up as an example of what would happen if a programmer went rogue and disregarded all rules and aesthetics of code formatting, and most who see it are horrified. All those macros? Short identifiers? Many statements on the same line? Entire functions on a single line, including those triggers of international debate, the curly braces?

Despite being misaligned with popular layout standards, is it really such a mess? It's small, so you can study the whole thing at once without scrolling. The heavy use of macros prevents noisy repetition and allows thinking in terms of higher-level chunks. That level of density makes the horizontal layout easier to follow than it would be with preprocessor-free C. (To be fair, the big downside is that this is not the kind of code debuggers work well with.)

I suspect I'm not seeing these two examples of extreme formatting the same way that someone who has programmed exclusively with languages of the C / Java / Javascript class does. I happily fused BASIC statements together with a colon, though I admit a moment of hesitation before attempting the same daring feat in C with a semicolon. J and Forth naturally have tight, horizontal layouts, and that's part of why those language cultures sometimes use quantity of code to specify problem difficulty.

"How hard do you think that is?"

"Maybe a dozen lines or so."

permalink October 29, 2014

previously

archives

twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?