T w e n t y S i d e d
My column this week answers some reader questions about the public reaction to Undertale, the use of 2K textures in games, and to the use of curly braces in programming.
There’s a lot more that could be said about curly braces vs. indentation for denoting blocks of code. I wouldn’t be surprised if someone’s written a whole book on the subject. This is because code formatting isn’t a decision tree between “right” and “wrong” but instead a series of trade-offs to be managed.
A coder will spend more time reading code than writing code, so making readable code is more important than than making code convenient to write. Sometimes reading code involves analyzing each line and figuring out exactly what it does, and sometimes it means skimming quickly through pages of the stuff, looking for one particular thing. Ideally code should facilitate both types of reading.
But what makes something “readable”?
Maybe you want blank lines between code blocks, which serve roughly the same purpose as the blank space between the paragraphs in this post. It divides the thoughts on a conceptual level, while also giving you visual markers so you can keep track of your position. Or maybe you want to minimize the number of blank lines, because you want to fit as much code onto a single page as possible.
Once again, it comes down to domain. Some kinds of coding have huge blocks of dense math and you want to give the complexity some breathing room. Other code has lots of short, obvious actions and you want to pack as much of it together as you can. So you end up with a coder who writes simulations getting in an argument with someone who writes user interfaces, and a networking programmer will be sniping at both of them. All three people have very different code. When the simulation guy advocates giving code more room to breathe, the woman writing user interface code imagines the impact this policy would have on her already-sprawling code. They end up in a flame war, because they picture using the other person’s formatting on their own code.
This isn’t helped by our need to standardize. You want one set of rules for everyone to follow so your project isn’t a mishmash of different formatting styles. But that One Set of Rules will work better in some areas than others. And of course, once you’re used to a particular set of rules then it starts to look more “correct” out of simple familiarity.
It’s a tough problem to solve, and it doesn’t help that our projects keep getting bigger. More code, more different kinds of code, and more different programmers working on the same code. It could be that obsessing over spacing is just an awkward phase we’re going through, and what we really need are more tools for easing the burden of reading code. Maybe some sort of visual cues for code flow, or new ways of coloring code, or something else outlandish that hasn’t even been imagined yet. Maybe we need to write more robust comments not for ourselves, but for the benefit of some Google-esque code search engine. In the meantime, we’re going to be left haggling over stuff like spacing, because right now that’s all we’ve got.
