Source formatting style seems like such a minor thing. I like one format for code, my colleague likes another style. Live and let live, right?
Unfortunately, it's not quite so simple as that, at least not when you might both be making changes in the same source code.
One of the trickier aspects of working as a team is that there will occasionally be conflicts in source code. This is especially true in an agile environment. Of course, you do your best to ensure that classes are as large as they have to be and no larger. That can help avoid unnecessary conflicts.
But there are likely to be some classes that are being frequently updated and if you and your colleague are both making changes, it's really important to agree on a common code format style. That's because differences even in white space can really complicate the set of conflicts and therefore make a merge much harder. And anything which is harder is more prone to errors.
Otherwise, let's say you make a change and check it in with your favorite formatting (X) applied. Meanwhile, your colleague is making changes using his favorite formatting (Y). When he comes to commit his changes, he's going to find that the file changed on him. He has to merge. He's going to hate it when there are lots of insignificant white space changes.
He's going to hate it even more if, for example, you've put in curly braces everywhere that they're legal and, under Y, all unnecessary curly braces are removed. There are a million ways to adjust the formatting of source code.
So, pick one style, and set up Eclipse or your favorite IDE to apply the formatting changes whenever you save. Then, before you commit your code, actually go in and do cleanup (you can run cleanup on your entire source tree at once). If you always follow that plan, it will ensure that the changes (and conflicts) that show up are exactly what the difference should be -- neither more nor less.
OK, back to work!
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment