My programming style is better than yours

Why talking about programming style feels like fighting a religious war. And how to make peace.

Most of the time, software engineers are a mellow lot. They come into work, sit in their little corner, commune with the machine, and go back home. Leave them to their devices, and they’ll leave you to yours. But ask them questions about their coding style, or challenge their programming idioms or preference of language, and the claws come out. Especially over programming style. No wonder it can feel like a religious war. For all the passion and ideological stubbornness they evoke, debates over programming style are almost like the clash of religious ideologies.

“You must indent your code with two spaces,” Zeh Lott, the lead developer on the team chided me for my blasphemous use of four. “It’s our convention.” I had asked Zeh for an informal code review — foolishly, as it turned out — and invited his disapproval over straying from the path of established convention.

“But Zeh,” I protested, “surely no one cares about the number of spaces, as long as it’s consistent and doesn’t mess up the code?”

“That’s our convention,” Zeh repeated, “to ensure uniformity of code.

“People expect consistency,” he continued, now raising a pontifical finger. “Readability is very important.”

Well, I can’t agree more with that, although I didn’t see how my program would be any less readable with four spaces instead of two. I’ve written programs all my working life with four spaces for indentation, and both man and machine have been able to read it with equal fluency. But I decided not to argue. It was taking time away from the actual code review — which, in case anyone’s wondering, is not about programming style.

Does that sound familiar? Yes, of course it does. Every programming team worth its salt follows a coding convention (or programming style) guide. It’s how team leads and principal software engineers keep their programming tribe conformant with a standard coding practice. It’s a necessary document for general programming structure, yes, but when team leads expect strict, unquestioned adherence, they rather miss the point. Different style guides have different conventions — naming variables in snake_case, naming variables in camelCase; putting curly braces on lines by themselves, putting curly braces at the end of a line; prescriptions for this, proscriptions for that; and on and on. Each of those styles ruffles someone’s feathers, but is equally sacred to the people writing it. Like to Mr. Zeh Lott.

Though it’s obvious that no coding convention guide is the absolute truth, they carry an air of fervent religious absolutism — even though any two contrary edicts can’t both be right. Like religions, coding conventions too have tribal origins; they spring from someone’s idea of how things ought to be done in their little tribe in their little corner of the world. They usually reflect the programming style of the author — the style they’ve always used, that they are comfortable with, that has stood them in good stead. Over time, those preferences harden into dogma — immutable, sacred, unthinking — and every opinion that deviates from that becomes heresy. And when that happens, the ideological battle lines get drawn, and the purpose of programming (building quality software) gets lost in the petty squabbles over which system is right. Much programmer blood is shed.

Look, conventions are just that — conventions. Guidelines. (Though some authors call them coding standards, indicating a stronger, stricter code of conduct). In the clamour to follow convention to the letter, we lose sight of what’s actually more important. Even if uniformity of appearance is a worthy goal, isn’t it more important to have well written code? Code that’s a delight to read? Code whose purpose is immediately clear, because the variables are well-named, the control structures are well thought out, the functions are small, cohesive, and loosely coupled? When customers pay for quality software, they’re not paying for braces put on lines by themselves or variables named like_this instead of likeThis, and certainly not for two spaces for indentation instead of four.

And what, I ask you, is the point of having a large unwieldy function that runs into a hundred and ninety three lines just because you had to honour the convention that said you couldn’t stop as soon as the output of the function was determined? That’s what we do in real life. In real life, we stop looking for answers to life’s questions once we find adequate ones (mostly). It’s called the principle of satisficing — a rather pleasing portmanteau of satisfying and sufficing. Why would we take on the cognitive load of keeping the extra pointless information in our puny brains? Yet, you’ve seen this programming style guideline, as have I. Just to not have a “break in the flow”, which returning prematurely from the function apparently causes.

But — you protest — what about consistency? Yes, what about that? Imagine there’s absolute, strict, unthinking compliance with certain established coding guidelines at your workplace. Can you guarantee that the code written by different programmers at different times will be consistent? In looks . . . possibly. In program structure? Not always. In function? Hell, no. You know why? Because people are different. They do even the same things differently. So why shoehorn them into exactly the same rigid structure? Why this insistence on following a coding convention to the letter? It doesn’t make for better quality code. It only makes for a Procrustean device. Yes, consistency is important, but not mindless consistency. Like PEP8, the Python style guide says, “A foolish consistency is the hobgoblin of small minds.”

As far as I see, there are three issues regarding code quality. Firstly, there are those stylistic issues. You do want to collect certain rudimentary styling recommendations in a style guide, but allow for leeway (unless it interferes with understanding the code itself). No one has the same sense of style as you do, so let it go. Every professional programmer should be able to read, write and understand different stylistic layouts. The more important thing is whether a reader can read and understand your code. A human reader, that is. Can a human read your program and understand what you’ve written, and why? Or are they going to get lost in the code, trying to match the opening bracket to the closing bracket to figure out where a block starts and ends?

Then there are idiomatic issues of a language. You omit parentheses after function calls in Ruby; you use list comprehensions in Python instead of for and append as in other languages; you use double exclamations (!!) in JavaScript to convert things to Booleans. Emphasize them in your conventions guide, but allow for flexibility as the situation demands. The people who work on your software projects are professionals, and professionals know what the rules are, and whether, when, why, and how much to bend them. Readability is always more important.

Finally, there are functional requirements. Those are the most important. Break up a function that’s doing more than one thing into more functions. Not by some arbitrary number of lines — as is commonly found in many style guides — but by the work it’s doing. It’s not always possible, but try — you might find a better approach to solving the problem.

. . .

Don’t get me wrong — I’m not saying burn all coding style guides and let the programmers run amok. That would be anarchy. All I’m saying is — be pragmatic instead of dogmatic. Structure is important, yes, but don’t let structure turn into stricture.

When you do code reviews, focus on code quality before code beauty. Beauty is extrinsic, ephemeral, in the eyes only of the beholder; quality endures. Over time, as the software grows, that quality will build a firmer foundation for the software. So look for the DRY principle, the Single Responsibility Principle, the Principle of Least Astonishment. Look for the Law of Demeter, Liskov substitutability, proper design patterns. Look for these, and educate others about them too. You’ll have a more enjoyable programming experience, and build better quality software too.

Finally, don’t stop having conversations. If you disagree with a convention, talk about it. Conventions are not gospel, and they’re not etched in stone. I have, for example, long yearned for an end statement in Python. There’s just such a . . . lack of closure . . . without one. Now, hardcore Pythonistas will recoil at this, but when I write Python (my favourite language, by the way), I define a little end statement:

end = 0

at the top of my source file. Then I can do this [1]:

def is_odd(number):return number % 2 != 0
end


if is_odd(number):
    print(f"{number} is odd")
else:
    print(f"{number} is even")
end

Though a bit hacky and ersatz, and admittedly whimsical, that end makes for a rather satisfying closure. Sometimes syntactic sugar is nice.

I also put my braces on separate lines in C++ and in JavaScript — I like the symmetry of how they line up. I use break and continue to interrupt loops. I’ve also committed . . . the Gravest Sin in all of programming. I’ve violated the most sacred commandment of every programming style guide.

I have used gotos in my C++ programs.

Yes, I hear the collective gasp of incredulity from my programming brethren. Breathe out, folks. Slowly. Breathe. It’s OK. Nothing bad happened.

. . .

Now for the twist in this tale. This wasn’t only about programming style, this was also about how humans interact with each other given differing ideas of what the right thing to do is. This was about how even the best of intentions can backfire, leading to conflict and misgiving. This was about replacing rigidity with flexibility; this was about nuance.

This was also about culture.

So if you’re a team lead, responsible for delivering high quality code, I hope you’ve created a culture where programming style is not a religious edict forced down your programmers’ throats; where dissent is allowed — even welcome; where you can trust your programmers to write good quality code despite their differing stylistic choices within a consistent, reasonable structure.

If you’re a programmer, I hope you can speak your mind without worrying about hurting people’s feelings; that you have the honesty to accept that a certain programming idiom is better than what you’re used to; that you can have a respectful dialogue when you disagree; and that you are mature enough to speak up — and listen — when something bothers you. If you only stew in your own roiling thoughts, you’ll just imagine things that might never have been, and you’ll only build assumption and judgment and resentment. Have a conversation instead.

And if you’re just starting out on your programming journey, please pick up a copy of Code Complete. It has very sensible, very pragmatic advice on programming style, far removed from dogma. Also check out Coding Horror, a site inspired by Code Complete. It also has a list of recommended reading for developers.

Happy programming.

[1] On mobile devices, the code does not format correctly. At least on mine it doesn’t. The indentation is lost as is the syntax highlighting.