db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@gluecode.com>
Subject Re: "Cosmetic" changes - type "B"
Date Fri, 21 Jan 2005 20:33:29 GMT
Daniel John Debrunner wrote:
> 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.

Just colour should this bikeshed be? :-)

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


View raw message