Have you ever used a coding style guide when working with a team? If you haven’t, it’s about time I introduce you to the concept. All well-disciplined teams, regardless of their specialty, have a number of ground rules that keeps them uniform. Every major newspaper and magazine has a style guide. If you’re going to start building a team, you might as well create one before people start getting used to coding all over the place.

A mentor of mine once told me: “Getting a team of developers to cooperate is just like herding a bunch of stray cats.” Coders all have their own personal ways to construct routines and modules. Each of them has a preferred framework, a preferred IDE, and a preferred flavor of doughnut to chew on while working. It’s what makes a coder who he/she is. But you can’t just let ‘em all roam freely. You and anyone you work with have to make some compromises to put a sort of leash around your nasty coding habits.

I’ll give you my bad habits. I coded in C, and I didn’t tab anything. I just swam through, wrote enormous headers with defined routines I would later find myself not using at all, and rarely commented. It was my style, and it worked. The moment someone looked at my code to add something, he said, “Why’d you even bother making this open-source? No one can read half of it!” This isn’t the way to code when you’re collaborating with someone. That’s why you should make a style guide for your team.

Here are a few things you should include in your style guide:

• Comments – Let them know where, when, and how much to comment. Neatly commented work will be easier to navigate.
• Tabbing – Definitely make them tab their code. Every new subroutine (while, if, select, for, etc.) should have its content tabbed even further. Recursive tabbing saves tons of time and makes your team more productive.
• Variable names – Each name should have a prefix. A string for a person’s name should be called “szName” or something like that. This helps the development process by reducing the strain on memory.
• Structure – This is very important. Consider having team members write with a certain “grammar.” In other words, have them include a comfortable amount of white space between routines, and capitalize certain letters in a variable.

When you can read each other’s code with proficiency, you save plenty of time. Communication is also key. Have regular meetings and keep an accurate record of everything everyone adds to the product. Within the meetings, don’t just talk about all the Red Bull you chugged while pulling an all-nighter on the development of a module. Talk about the module itself. If you don’t establish some rules of uniformity, you’ll have a herd of stray cats that can’t finish something on time.

Be careful not to make the guideline too specific, though. Coding is still an art, despite all the computer-related stuff you’re doing. It’s best to let at least a minimal amount of personality seep through the seams!