There comes a time in everyone’s life when appearance becomes important. Usually, it’s around the teenage years. For some it’s earlier. But by high-school time, c'mon. What girl can resist the pretty red dress on display in Nordstrom when Prom is around the corner?
And so too comes the time in developers' lives when we become confident in our programmatic skills and start looking elsewhere to improve. In high school, we might splurge on a superfly jacket with a collar to pop up higher than Count Chocula. In nerd-world, we might stare at a LCD until our eyes go cross and we say something like, “hmm… what this line could use is some whitespace.”
And so begins that teenage phase in programming, and instead of brushing our hair and checking out our jaw-line in the mirror, we’re smashing our face on the spacebar and pointing to our Github and yelling, “MOM! LOOK HOW PRETTY MY CODE IS!”
Some people pick up this habit after they’ve written enough for loops to write a permutation function while driving to work with their feet and explaining to Aunt Becky for the tenth time that, “No, Aunt Becky, Chicago is not a continent.” This type of Pretty Coder is made. Others are born into Pretty Code, learning it from the start, and these unfortunate souls, to me, correspond to the Toddler’s in Tiaras of the programming world.
But whether you were born into Pretty Code, or you picked up moonlight typesetting as a hobby to kill time after how awesome your for-loop skills got, I’m here to explain why, objectively, Pretty Code is bullshit. And here’s the TL;DR:
Pretty Code ain’t pretty.
Let’s first establish what Pretty Code is, and why it exists, because that’s all that’s needed to completely destroy its case. Let’s use the least impractical case of Pretty Code first and look at two equal dictionaries:
1 2 3 4 5 6 7 8 9 | |
1 2 3 4 5 6 7 8 9 | |
As you can see above, one of these blocks is labeled ugly and the other pretty. Pretty Code, as shown above, is the “art” of lining up pieces of code with whitespace.
We can deduce that Pretty Code isn’t done to speed up coding, right? Like how are you possibly adding in that whitespace faster than not adding it in? You’re not. It’s not faster to write code this way.
Your shiny, new i7 isn’t looking at its fingernails and saying, “You know, I was going to run this dictionary slow, but then I saw how pretty it is, so let me get back to work and start executin' like a G.” Right? We know whitespace has no effect on performance.
So, the only reason I can see to Pretty Code is because it “looks” better. The key word here is “looks”.
“Why do I care how code looks,” might say the Pretty Code naysayer. And the advocate would say, “because you read code more than you write it.”
And the Pretty Code advocate is exactly right. And, in being so, completely destroys his case. We read code more than we write it. Far more. So it ought to be readable. Who said anything about “lookable”?
Have you ever written one line of code:
1
| |
And decided, “you know what this line needs is… whitespace… lots of whitespace.” and, with that thought in mind, refactored it to:
1
| |
No.
Why? Because that line is less readable. It doesn’t magically become more readable if the line below is:
1 2 | |
Pretty Code looks better, yes. But looking at code isn’t important. Reading it is.
You read code at the line level. You look at it at the multiline level.
Pretty Code makes (octo)cats cry.
Okay, so you don’t care how readable your code is. You just care that you can say, “MOM! COME LOOK AT ALL MY WHITESPACE!” Fine. You can write your own code however you want.
But, if you’re in a team, and you probably are if you’re a professional, and you theoretically are–at the very least–if you’re part of the open source community… you should maybe consider revision history (and readability).
Let’s say that Product comes back and they say, “Dammit, Jimmy, we need a new key in that dictionary. The key is virtual_phone_bank and the value Sign up and start saving babies RIGHT NOW!. Chop, chop.”
So, you open up ./src/config/locales/en.js and you see:
1 2 3 4 5 | |
And you stop for a second to admire how beautiful it is, and then you press i and get to work. But quickly, you’re stumped:
1 2 3 4 5 6 | |
“Oh, no!” you think, “it’s so ugly!” and after your eyeballs are black and your nose is bloody and you’ve slammed your face on the spacebar a grand total of 18 times, you can go back to saying “Mirror, Mirror, on the wall, who has the most whitespace of them all?” And you’ll know the answer is you, because your code now look like:
1 2 3 4 5 6 | |
And, now that you’ve worked your typesetting wonders, not only is there the problem that by the time my eyes get to “Help the president…” that they’re so far removed from “disco” that I have to look back to remember what I’m even assigning to what… but also, you’ve just changed that line of code, and when Teddy from Product goes through to figure out who to fire for putting a joke line in the code, you’re going to have to say, “But I didn’t even write that line! Swear! I just made it pretty is all!”
Yes, modern tools make it easy to see the entire revision history of a line. But, yes, revision history is still important anyway. How code “looks” is not. How it reads is very important, and this does not read well. No, it does read well at all.
Pretty Code is impractical.
Finally, let’s explore why pretty code isn’t even practical in the first place. Because if you’ve gotten this far, and you’re still on board the Pretty Code Express, maybe this can totally derail your world.
1 2 3 | |
If you’re not the type of Pretty Coder that lines up similar functions, thank Stroustrup. But let’s assume you are, and let’s assume you also don’t care about character line limits, and all you care about is how your code “looks”.
You’d end up with:
1 2 3 | |
Which, A) reading that now makes me want to cry, and B) writing that made me want to punch a baby. I mean, I literally have three black eyes and two broken noses and my spacebar key doesn’t even work anymore. I had to remap it to “CAPS LOCK” because I already broke all the other ones pretty coding with my face so hard.
Anyway, back on topic… Imagine adding two more links to the links property in the third render:
1 2 3 | |
Not only can I not read a single line of that code, not only have you shitted on the revision history with gusto (twice now), but–also–it looks absurd! And that’s what the whole point of Pretty Code is, making code look good.
The bottom line is, Pretty Code isn’t practical. You can add all the whitespace you want to your dictionaries. But, please, no matter what a typesetter tells you, there is no unnecessary whitespace in the open source world.
So the next time you’re bored out of your mind, and you’ve got out your hair brush, and you’re talking to your mirror, and you’re about to Pretty Code… think about us, the ones reading your code. And, think about the spacebar, poor old Mr. Spacebar.