Coding Horror is often fun, and a good read, particularly for aspiring techies who want an inside glimpse of some of the details that would make up your life if you pursue that path. But when I read Jeff’s post on spaces versus tabs in code formatting I both cracked up and immediately thought of one of my Data Structures students who has to reformat any piece of code he is given before he starts working with it. With my students deep into their team projects, I wonder if they are running into the conflict that Jeff claims is inevitable:
The only programming project with no disagreement whatsoever on code formatting is the one you work on alone. Wherever there are two programmers working on the same project, there are invariably disagreements about how the code should be formatted. Sometimes serious disagreements. The more programmers you add, the more divisive those disagreements get. And handling those disagreements can be .. tricky.
He goes on to discuss the pitfall of team members taking it upon themselves to “fix” each other’s code – not just spacing, but even variable name conventions and the like. It may seem odd that such computationally trivial decisions (I mean, we all know the compiler doesn’t care…) could cause so much interpersonal strife on a team. But if you’ve ever really gotten into programming, the idea that someone else might be messing around with your code, after you get it how you like it….. well, it is probably at least a little agitating. And Jeff cites the classic “The Elements of Programming Style” to illustrate that these style principles actually do matter when it comes to code as a tool for comprehension and communication. Which is particularly key on a team project.
In their book called The Elements of Programming Style, Kernighan and Plauger also identify what we would call discourse rules. Our empirical results put teeth into these rules: It is not merely a matter of aesthetics that programs should be written in a particular style. Rather there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified.
I am now curious to see how my students navigate this problem – if they try to get consistency or not, and if the most obsessive person in the group just wins (I fear I have one group with people who don’t care that much and one group with people who do). And it makes me think about the style guidelines I set out for code in my introductory class, and that perhaps sharing some of this research would make it clearer why I have those standards.
