Programming style

For all that the craft of programming is clothed in the language of science and engineering, writing software is an inexact, messy process. The term “programming language” is an apt one — to build a program, you have to talk to the computer, and programming languages come with the same ambiguity, fragility and plurality of ways to say the same thing as languages for talking to humans. People even write poetry in code.

And so, if two people write the same program, they will write it differently, just as when two people write the same essay, or take the same photograph. Programming is a weird and alien form of communication, used to communicate with systems very unlike humans, but it is definitely communication.

Not only do different people write programs differently, they write them differently in a more or less consistent way — that is, they have a style. Some more notably than others. You can study a piece of code and probably figure out which of your coworkers wrote it, if you’ve seen a reasonable amount of their code before. And I don’t mean what is usually called “style” in programming — syntactical style, the placement of parentheses and whitespace, often enforced and standardized — I mean style in terms of structural idiosyncrasies, differences in the flesh and bones of a program.

I’d be hard pressed to eloquently describe my “programming style” or that of any other programmer whose style I know well enough to identify. We don’t really have the words for it yet. It’s a little easier to speak of motifs, ways a programmer usually chooses to express some flavour of subconcept. Do they prefer comprehensions and combinators over explicit construction? Many small files or a few long ones? Do they tend to break down problems as classes, namespaces or functions? But none of those by itself is a “style”, per se.

Something artists often do is study and learn to mimic the styles of other great artists. Perhaps that’s also a worthy pursuit for a programmer.

Show Comments