The Case for a Team Standard
Editorial Note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, check out CodeIt.Right and give it a try.
In professional contexts, I think that the word “standard” has two distinct flavors. So when we talk about a “team standard” or a “coding standard,” the waters muddy a bit. In this post, I’m going to make the case for a team standard. But before I do, I think it important to discuss these flavors that I mention. And keep in mind that we’re not talking dictionary definition as much as the feelings that the word evokes.
First, consider standard as “common.” To understand what I mean, let’s talk cars. If you go to buy a car, you can have an automatic transmission or a standard transmission. Standard represents a weird naming choice for this distinction since (1) automatic transmissions dominate (at least in the US) and (2) “manual” or “stick-shift” offer much better descriptions. But it’s called “standard” because of historical context. Once upon a time, automatic was a new sort of upgrade, so the existing, default option became boringly known as “standard.”
In contrast, consider standard as “discerning.” Most commonly you hear this in the context of having standards. If some leering, creepy person suggested you go out on a date to a fast food restaurant, you might rejoin with, “ugh, no, I have standards.”
Now, take these common contexts for the word to the software team room. When someone proposes coding standards, the two flavors make themselves plain in the team members’ reactions. Some like the idea, and think, “it’s important to have standards and take pride in our work.” Others hear, “check your creativity at the gate, because around here we write standard, default code.”
What I Mean by Standard
Now that I’ve drawn the appropriate distinction, I feel it appropriate to make my case. When I talk about the importance of a standard, I speak with the second flavor of the word in mind. I speak about the team looking at its code with a discerning attitude. Not just any code can make it in here — we have standards.
These can take somewhat fluid forms, and I don’t mean to be prescriptive. The sorts of standards that I like to see apply to design principles as much as possible and to cosmetic concerns only when they have to.
For example, “all non-GUI code should be test driven” and “methods with more than 20 lines should require a conversation to justify them” represent the sort of standards I like my teams to have. They say, “we believe in TDD” and “we view long methods as code smells,” respectively. In a way, they represent the coding ethos of the group.
On the other side of the fence lie prescriptions like, “all class fields shall be prepended with underscores” and “all methods shall be camel case.” I consider such concerns cosmetic, since they concern appearance and not design or runtime behavior. Cosmetic concerns are not important… unless they are. If the team struggles to read code and becomes confused because of inconsistency, then such concerns become important. If the occasional quirk presents no serious readability issues, then prescriptive declarations about it stifle more than they help.
Having standards for your team’s work product does not mean mandating total homogeneity.
