B) Re-formatting. Changes in this group are a nightmare. :-( Because everyone has a different idea of what the correct formatting is. It also tends to make life difficult for someone who is modifying the file as any format cleanup will tend to cause merge failures. I'm loathe to even raise this because of the endless discussions that can ensue.
<warning> Just colour should this bikeshed be? :-) </warning>
I think the challenge here is in agreeing what the style should be - once that is done then reformatting the code can be done automatically by an IDE in a big, one-time, format-only fix done when people do not have a lot to merge.
Personally, I would like to know what the formatting rules are and then just set them up once in the tool - this means that you don't fight the IDE when editing. We took this option with Geronimo (as we started from scratch) and shorted circuited the argument by making the format "the default layout from your IDE" with a couple of tweaks, relying on the assumption the IDEs people were using (mainly Idea and Eclipse) were very similar.
Unfortunately, that layout is different from the layout for the majority of the Derby code I've seen to date so may not be acceptable or popular. The alternative is to publish a template for each IDE with the project's rules in it.
I prefer this to Brian's approach of automatic re-formatting using ant or a svn hook as:
1) no rule can't be broken, so having a layout that is non-standard
sometimes make more sense
2) the "format as you type" features of IDEs (OK, IdeaJ at least) seem
to be less agressive than tools intended for a one-shot reformat
3) there isn't the potential to forget running the tool before checkin;
conversely, there isn't the potential for an auto-format to mess up
something critical during the commit process
-- Jeremy
