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.
The 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!
Code Reading
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.
John Blanco
John Blanco is a freelance iOS developer living in Lakewood, Colorado. He's been developing mobile apps for over 15 years, beginning in the medieval days of Java ME and Blackberry and all the way through iPhone and Android! He's led development on dozens of apps across a wide variety of domains such as retail, vision, orthotics, games, sports, and more!
Follow Me:
Using MotoBlur as a Dev Phone Comments Never Get Out of Date
Comments are currently closed.
17 thoughts on “Coding Standards Are a Farce!”John Blanco
I've been writing mobile apps professionally for 10 years: Blackberry, Java, ME, iPhone, Android. I've gotten dozens of apps into the various App Stores for dozens of clients, big and small.
My current specialty is in iOS and Xamarin development. If you need an app written at a fixed price or just need a hourly developer to give a boost to your current team, I might be your guy.
Let's make an app!
Good points. I especially like the idea of “teaching by example.” But that dude Dave still likes coding standards. :-)
You may like coding standards, but to take Double Encore as an example, it does appear we’re all already coding in similar styles already. Except for dealloc’ing which, after today, is a total CF. :-)
Wow! That’s a relaly neat answer!
Code standards can be ways of encouraging people not to do stupid stuff, like using private getters and setters, pointless lazy initialisation, leaving wads of commented-out code around.
Also, if you don’t fix on a standard, then two devs using IDEs set to autoreformat will continually make massive diffs for small semantic changes.
True, Ricky. But those developers will resolve those problems quite quickly by themselves or with each other. I have never worked at a company that had a standard saying, “Set your editor to use these tab settings of these widths, etc.” It’s not necessary, those problems are so glaring and annoying to the developer’s effected, they are fixed quickly.
No need for a standard.
All of this makes me wonder what advocates of coding standards think of Emerson. Then again, perhaps some do not. :)
It is a very valid point that coding standard are not the first point you should discuss when starting a project. What IDE you use again has nothing to do with coding standards. If somebody is telling me what tool to use to write TEXT FILES then just tell them to GTFO and continue to use them.
But “Coding standards are a farce! Let them die.” Srsly? It seems you haven’t ever worked on a huge project, or at least on one which has the potential to become huge.
Coding standards are not meant to tell you what letter interface names should start, but to prohibit programmers to:
1) apply different coding standards and fight over them
2) write spagetti code with gotos, multiple return statement, variable re-use, parameter re-assignment, invalid constant names and so on and so on (language syntax is too loose!)
In java land checkstlye is a good place to start. Additionally coding standards must be enforced within the ide or build chain! I.e. you should get a build error if you brake the rule instead of having ongoing arguments with you reviewer colleagues about whether to follow the standards or not.
However, if you don’t have a huge project, or you are ok to rewrite/abandon the source every year, or you do not have a responsible and skillful architect in the team who can define and enforce the rules, or your colleagues are not willing/able to follow such rules, you should not even try. But you won’t be able to maintain, expand and add new features to your codebase at a very soon point.
Wow … have you ever worked on a project with more than a few people? Real programming teams use these things called “diffs” … a lot: they use them for code reviews, they use them to track down “who broke X?”, they use them to resolve conflicts between commits, etc. If everyone just formats everything, or worse re-formats everything their own way every time they touch an area of code, your diffs very quickly become completely worthless, and you get a TON of annoying conflicts between everyone’s work.
Now, I’ll buy that code standards which evolve organically are much better than ones where a single developer tries to force their tastes on others. But to say “code standards are meaningless, they just make the code pretty” is to reveal a complete lack of experience in a team environment, where “stepping on each other’s toes” is a serious issue.
I’ve worked on HUGE projects, Jeremy. And you’re quite right. And when that happens, the person makes a change because no developer would tolerate having to commit changes that were all whitespace. That change becomes organic, it need not be enforced by a single authority.
I never said developers should ignore working as a team. I said the problems that fix themselves organically are the ones that matter. All else is pedagogy.
It’s often an issue of too little lithium. Most of the code produced by programmers who refuse to agree to abide by a simple set of standards commit Java code that looks like this (and think their shit don’t stink):
public class __bozo
{
\tprivate
\t\t void Execute(Date psz_l_nm) {
Vector x = null;
x = new Vector(); // create new vector
long i = 1l;
for (; i <= 10; i++) // loop 10 times
\t\treally_long(); // call D method
}
public static void really_long() { int x = 5; // 5
// … 500 lines here
}
private String o;
}
Coding standards do not prohibit creativity. Lack of coding standards wastes time, particularly due to the more junior team members and the ones with stronger cases of mania.
Coding standards won’t fix that, simple education will. If a lack of coding standards produces that result, you need to consult with your interviewer. :-)
Coding standards are overrated :thumbsup:
If your code standards were simple, small, and collaborative it sounds like you have no objection. We agree that the code should become the coding standard. We agree it shouldn’t be rammed down one person’s throat by another.
Check out our reasoning.
Check out our writeup:
http://agileinaflash.blogspot.com/2009/02/coding-standards.html
Of course coding standards limit creativity. EVERY standard by definition limits creativity. That’s what they are for. But our goal is to have them define only enough that people don’t waste time on silly differences, such as the rule that people commenting this blog used some form of English and some recognizable (at least phonetic) spelling standards. If we don’t limit silly, personal, idiomatic differences then sombl8y will jvrst a;lskj 8i90908 jsl;sls the j/a/lkjd with buiod^&&e, right? And then where would we be?
Uh, so you’re suggesting that there is some standardization in what “education” provides.
I’ve met plenty of quite capable and intelligent programmers who produced code that worked very well, and yet it looked like this shit. The only way for an interview to solve the problem would be that it was based on some sort of standard.
Right.
Not at all. I’m suggesting that not having a coding standard is not some license to just type whatever you want and call it code. I’m saying you don’t need the dogmatic standard, but peer pressure and learning from one another and learning from the community in general will (A) pull the code together and (B) educate developers on the important stuff rather than insisting that dogmatic style guides are what’s important.
I’ll buy that, to an extent. A standard should always evolve as necessary, and should also be obvious from reading the code. If it doesn’t, you don’t have a team, just a bunch of self-absorbed, arrogant developers who haven’t figured how to play well with others.
In any case, whether you start with a “dogmatic” standard or whether one evolves from peer pressure et al, you still should end up with a standard. And the people who violate the standard should be smacked upside the head. I can’t think of anything dumber than wasting time with formatting-oriented diff issues, or pulling up a file where it’s half tabs and half spaces, or trying to decipher some monkey’s crap code who still thinks Hungarian notation is a good idea.
Now you’re getting it. :-)