— This post, on code standards, is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —

One of the biggest differences between writing code at school and writing code today has been the need to work with, interpret, modify and/or rewrite code that my teammates have implemented.

It”s been a humbling experience, to say the least.

Everyone has their own habits, their own rhythms, and their own way of thinking about code patterns & implementations.

And when you don”t draw a line in the sand upfront, things can get messy, really, really quick.

So, one of the biggest boons to team morale (not to mention, my sanity), in the last 12 months, was when the team, together, developed coding standards to adhere to.

And the biggest boon was when we actually started following them.

Here are the standards that, in my experience, have been the most helpful in keeping both team morale & team sanity up:

– Introduce indentation standards. It” really simple. Just nest if statements, loops, and function declarations with tab indents. It allows my eyes to scan code 3x faster than when for loops, if statements, and methods aren”t indented. And that”s just fantastic.

– Comment every method you create. We list the preconditions, postconditions, return variables, and input variables for each method in our code base. We have a standard comment template that is already formatted to receive these values. Here”s what it looks like:

/*********************************************************/
// - Input vars:
// - Preconditions:
// - Postconditions:
// - Returns:
// - Comments:
// -
// -
function Name($InputA,$InputB,$InputC,...) {
//Method code goes here
}

– Introduce variable & method naming standards. Simple standards around how you name your variables can help code readability a lot. Start with simple things like what to do with individual words in variable names ($AVar or $avar?), whitespace ($A_Var or $AVar?), upper & lower limits on length.

– Make code granular & reusable. This is another one that sounds like a no-brainer, but in practice sometimes it”s a hard one to stick to. There”s an entire body of academic research on why your code should be de-coupled and cohesive.

– Find & follow a standard design pattern. The nice thing about design patterns is that someone has thought out the common issues and written rules for you to follow. For me, Model-View-Controller has made my life so much easier. If you”re writing a web app, that”s probably the main design pattern you”ll want to familiar with.

– Peer architect. I like the practice of talking over solutions with teammates before I implement them. It”s a useful way to lay out your design theory and test your assumptions, before you actually write a lick of code

There you have it. I”d be interested in hearing what standards your team has developed, and how you enforce them / make sure you stick with them.

Oh, and if you want to follow musings of the awesome development team I work with, please do so here: @nleach @aycaaksu @maxstoller @maxmeyers, and @zeve .

Note: Any information of proprietary value to my employer has been removed or approved, and this post has been approved by my employer.