Coding Standards Are a Farce!
As young companies prosper and development teams grow, the inevitable conversation always becomes about agreeing on a set of coding standards that every developer must rigidly follow. We’ve all been there for the same tired meeting.
“Every one of us most write our code the same way to be successful.”
“But we’ve had success. Why should I be forced to place my curly braces on their own lines?”
“Because it will make our code look clean! And you have to preface your instance variables with m_, too!”
“Why? My IDE already identifies fields and gives them their own syntax color, too.”
“Not anymore, we’re not allowing the use of Eclipse anymore, it’s too slow to use!”
“If I can’t use Eclipse, then you can’t start your interface names with the letter I…”
…and so on, and so forth…
I’ve never quite gotten it. No company I’ve ever worked for started on Day #1 with a set of coding standards. The initial team usually just happily hacks away until either (A) the company dies or (B) the company thrives. When the latter happens, they hire more developers and then the coding standard talk comes about.
But why? I mean, sure, coding standards can make your source code look more homogenous, like it may have been written by a single developer. But, it wasn’t. Now, you’re forcing all your developers to code in one style that nobody (but the implementor) will like. They won’t be as happy. They won’t be as free. Their muscle memories will continue to type the way they always did, and continue to do at home, and they’ll constantly have to correct mistakes. The lead developer will see the offenses in the source repository and send obnoxious emails that say, “Uhh, yeah-h-h-h, you didn’t place all your variable definitions on their own line in two of your files. We went over this. Fix it!”
On top of all that, the code will never be homogenous because you can never standardize on talent and ideas. Solutions will vary in complexity, and the reader will notice.
Coding standards are a farce! Let them die.
If Not Coding Standards, Then What?
I’ll tell you what. If you want your developers to form into a cohesive unit, don’t push coding standards on them. Let them do what comes naturally, don’t disturb that force. What you should do is focus on education and teaching by example.
Recently, I joined Double Encore in Denver and, as expected, I met up with a lot of new coding styles that I wasn’t familiar with. One of our Dev Leads, Dave, did a presentation on Memory Management in Objective-C and while I disagreed with a couple things, there were some new things I found simply bizarre. One was to avoid using XCode templates when writing code.
What?? No templates??
Yes. The point of it was that our view controllers tend to get filled with bunches of empty functions that are filled with Apple commentary on what to do. We have stretches of them that go (properly) unimplemented. It bloats up our source and can make it hard to easily pick out the good stuff when reviewing the code.
(On top of that, the templates don’t call [super loadView] which leads to all kinds of crashes. But, I’ve outlined that and other grievances in 10 Things Apple Could Do to Make iPhone Development Perfect.)
When he said to stop using templates, I thought it was ludicrous. The next day, I gave it a try practically out of spite. This was stupid. I was supposed to create UITableViewDataSource objects without the template? Grotesque. Well, what I found was that it actually is pretty easy. The XCode autocomplete successfully fills in about 95% of the methods you need and, sure enough, you find that your source files are easier to read.
So now I don’t use templates anymore.
Now, did I need to have a coding standard imposed on me? Not at all. I was perfectly happy and willing to use templates. I tried it, and I liked it. I was sold. I believed. I wasn’t forced to do it because “it’s better this way, trust me,” I do it now because I really believe it to be better. What a world of difference!
If I started a development company today with a dozen developers working for me, I would want to get everyone doing the important stuff. Unit testing. Following a methodology as a team. Improving debugging techniques. Learning the language completely. Mastering the platform. Learning new third-party tools that make us more productive and ease our workload.
I wouldn’t teach it myself, I’d have the developers teach themselves. Slicing out some times each week for a presentation is a decent start, but it’s going to feel authoritarian and forced. Were you ever in a brownbag about a new application framework you didn’t want to use but your manager was all excited about it and you knew you were doomed to its standardization? What I’d really prioritize is actively encouraging my developers to send code to one another to review.
Code reading is the single best activity any developer can take part in. Much like book learning, the advantage is that you’re learning things you never thought to. Think about it, when you run into a problem you do a search and likely end up googling your way out of it. You got the code segment you were looking for, plugged it in, and your feature is now complete. But, when you do some code reading on an open source project or yours peers’ work, you are exposed to all manner of techniques you didn’t even know existed.
A fellow consultant of mine learned just a couple weeks ago that you can send messages to nil without a crash. In fact, it’s encouraged. Now, in almost every other language, this is something you spend a lot of time avoiding! In his case, he was a long-time Java developer who grew up on avoiding null references. Not only did he not know about this language difference, he never would have thought to even look it up! It never occurred to him it would be possible! Now, if he had read an Objective-C book cover to cover, there’s no doubt he would have learned that. That’s the difference in both book reading and code reading, you learn outside the box.
Try it. Take 10 minutes, and read as much source as you can of the WordPress iPhone App. Don’t try to understand how the whole app works together, just read individual classes. Read the code. I guarantee you will learn no less than 5 new things in those 10 minutes — probably more!
And when a team learns together, they code together. They will begin to share not only coding styles, but coding techniques, and by not only learning the best way to do things, but to adopt them without force, it becomes natural and empowering.
Because. Quite simply. If you have to force someone to code a certain way, it’s probably not important.
UPDATE: Based on some comments, keep in mind that not having a set of coding standards does not mean the apocalypse of horrible programmers are now free to reign terror on your codebase. Physical beatings are also a teaching tool. Also, some form of talent is required. No monkey coders.