Code Formatting in Agile Teams

Whether you work in an Agile team or not, one of the crucial aspects of team work is agreeing your team's code formatting rules. You may wonder why I’m using the word crucial when introducing this topic and the answer lies in the consequences of not using a common style.

Firstly, other programmer’s coding styles can be down right annoying, especially if they’re a long way from the norm. I once worked on a project where one programmer insisted on removing all indentation, checking in code that looked like this:

public String appendString(String[] values, String separator) {
StringBuilder appendedStr = new StringBuilder();
for (int i = 1; i < values.length; i++) {
appendedStr.append(values[i]);
if (i < values.length - 1)
appendedStr.append(separator);
}
return appendedStr.toString();
}

The code may have worked, but no one else code read it with the result that a common code formatting style was quickly agreed upon and introduced.

Secondly, and this is the most important factor to me, you loose the ability to compare different versions of the same class using your source control system. This is because source control systems will mark a reformatted line of code as a changed line of code, making it impossible to differentiate the genuine changes from noise.

Thirdly, using different formatting styles makes your code look unprofessional, putting you and the rest of your team in a bad light.

Lastly, sucky code saps moral.

Defining a team code formatting style shouldn’t take long, and I suggest starting with your IDE’s built in style and working from there, adhering to as many industry doctrines as possible. For example, I like eclipse's default style, but I also like to remove some of the bits of its generated comments that become unnecessary when you choose good argument names (something I’ve covered in my blog on comments).

If you’re using eclipse, then once you’ve got one installation set-up correctly it’s very simple to export that installation’s preferences to all the developers in your team. The easiest way of doing that is to select File | Export displaying the following dialogue box and then to select preferences from the Generalfolder. Once done press Next:

Now, select all the preferences that you want to make common throughout your team and save your file:

Once you have this file, send it to all the members of your team plus, store it somewhere safe: in the cloud, on a shared file system, document repository or source control system. It doesn’t really matter where just so long as you don’t loose it and it becomes known as the master copy.

Once this file is generally available the rest of your team needs to import it into their development environments. This is also very straight forward being the opposite of Export. To do the import select File | Import to display the following dialogue box and follow the instructions:

Remember that if everyone in your team uses the same formatting style, you can’t guarantee that your team’s code will be good, but you can guarantee that everyone can read it quickly and easily and will be able to compare different versions of it.