I’m Old, Part XXXIX: The One True Brace Style

There are few things that can rouse the ire of a programming than inconsistent or unusual brace style. At the same time, there are very few things that matter less in your code.

I will admit to favoring something close to K&R. If you’re curious, Wikipedia has a complete list of styles including the correct style and a bunch of abhorrent variations. Ha-ha! I kid! All of the brace styles in there are terrible. To somebody.

Before Adobe, I mostly worked solo on projects and the code style was pretty uniform across the project as a result. Working on Acrobat – that was a whole different matter. The Mac-only code-base was written by three or four engineers and included a fair amount of cross platform code that was written by several other people. All of us had varied backgrounds. Of course I followed K&R, I learned C at Bell Labs.

Still, each of us carved out our own special chunks of functionality and morphed them into our own styles. Where things got funny was when we had to interact over code. Pair programming, really. This usually happened when someone was stuck on a problem. This happens all the time and usually the answer is right in front of you, but you need another set of eyes to see the missing semicolon or uninitialized local or whatever.

Alan Wootton, who was the anchor of the Mac team, was particularly good at spotting problems. However, there was a price to getting his help. Alan had a process of working through other people’s code, and part of that process was to manually transform the brace style in front of him to his own, which was closer to Allman, which is more like Pascal style. Not surprising really, Alan did a lot of Pascal programming.

But watching it. It was like watching someone go through an art gallery of your own work and nudge all the paintings out of square. Brrr.

But he’d inevitably find the issue, fix it for you and check it in, making all his brace changes permanent.

Here’s the thing though -and I know it’s heretical- it doesn’t matter. Honestly. Brace style doesn’t matter. Getting wound up over brace style is akin to getting worked up over pop/soda/coke or sub/grinder/hoagie. What matter is the code in a bigger picture. How is it structured? Does it make sense and strike the right balance of abstraction? If you’re having trouble reading the code, that’s a smell. Go ahead and attend to it, but be prepared to embrace any style.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.