views:

104

answers:

4

Hi,

I'm currently part of the team implementing a new version control system (Subversion) within my organization. There's been a bit of a debate on how to handle code formatting and I'd like to get other peoples opinions and experiences on this topic.

We currently have ~10 developers each using different tools (due to licensing and preference). Some of these tools have automatic code formatters and others don't.

If we allow "blind" checkins the code will look drastically different each time someone does a check in. This will make things such as diffs and merges complicated.

I've talked to several people and they've mentioned the following solutions:

  1. Use the same developer program with the same code formatter (not really an option due to licensing)
  2. Have a hook (either client or server side) which will automatically format the code before going into the repository
  3. Manually format the code.

Regarding the 3rd point, the concept is to never auto-format the code and have some standards. Right now that seems to be what we're leaning towards. I'm a bit hesitant on that approach as it could lead to developers spending a lot of time manually formatting code.

If anyone can please provide some their thoughts and experience on this that would be great.

Thank you,

Martin

+3  A: 

If #1 isn't a viable option, #3 is probably your best choice. #2 would make it rather difficult for individual developers to do diffs between a working copy and the existing file after they've checked it out and run their own formatter on it at least once.

Option #3 is mostly about getting people into habits - code formatting isn't really that troublesome if everyone can get into the same habit. The only code you have to format is that which you create/touch; the rest will be formatted from checkout.

Amber
+1  A: 

If you run a script that formats code in an accepted format (and have nightly builds that tests this code everynight) then you can have a pre-commit hook for the SVN checkins that can enforce this standard.

However Option #3 is best as it is easier to set formatting rules in IDE while developing.

omermuhammed
+7  A: 

Don't let the tools/developers automatically/manually reformat the code just for aesthetic reasons. Diffing between revisions becomes a nightmare. Have a coding standard and try the toolsets to get new modules to conform as best as you can. People modifying an existing module should stick to the conventions used in that module whether they like it or not.

Trevor Tippins
+10 upvotes if I could. Get rid of the code formatters. It is much more important to be able to see/blame what changed from one rev to the next. Use coding standards to deal with new code going forward, and learn to "accept that there are things that we cannot change", when addressing old code that looks ugly.
Chris Thornton
A: 

I don't know if this is a technology issue or a culture issue.

Even if they are all using the same tool, most tools allow you change the default formatting rules applied to text.

Define some standards, enforce them through peer review and a cultural understanding of why it is important.

Michael Shimmins