Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

First, +1 on not introducing dependencies on a/any IDE.
(eclipse today...back to vi tomorrow ;)  Long Live Ant!

Tony Falabella wrote:
> I see your point now. 
> 
> Actually it is not enough for us to set up the format template to just 
> perform indentation, we will have to have it sort methods/attributes at 
> least by name, and by modifier (according to recommendation in the book). 
> 
> This should then accomplish what we need.

I am personally not accustomed to having an external automated tool 
exert so much control over my code.  However, if the group or Rod feels 
that the above requirements need to be enforced programatically for the 
health of the project, I could be convinced.

> 
> I can't comment on whether or not Eclipse settings would also do the 
> same thing, but I don't think we should require all developers to use 
> Eclipse (and if everyone does not do the same thing consistently there's 
> no point in doing any of this).

The consistency issue is really my main point, and I'm concerned that 
even having an automated tool will not mitigate this risk.  (are other 
open source projects doing this?)

It seems reasonable enough to set some guidelines, enforce them by group 
dynamics, and leave code consistent to the way you found it.

This is simple and ease to implement.

Bill

> 
> If our format template includes sorting, do you concur that it should 
> address our needs?
>   
> 
>  "William G. Thompson, Jr." <wg...@rc... 
> <mailto:wg...@rc...>> wrote:
> 
> Tony Falabella wrote:
>  > Bill,
>  >
>  > I believe the main point of the exercise is to easily see diffs in
>  > changes in the repos. As such, I believe issue #2 has to be ruled out
>  > (please read on).
> 
> The issues with diffs is exactly why #2 is important. In other words,
> unless the the automated mechanism can be garunteed to only munge code
> changed by a developer, diffs will get corrupted. I have not used
> Jalopy, so I can not comment on its consistency.
> 
> The diff problem is easily solved if #2 is our mode of operation. The
> goodliness of the code formating can be solved simply with the correct
> eclipse settings. This does not rule out the one-time reformating of
> the code base.
> 
> Bill
> 
>  > My thoughts are I will check out ALL code the first time, run it through
>  > the formatter with an agreed upon template and check it back in
>  > (comments for checkin will be something like "reformatted to group
>  > standard format").
>  >
>  > After that, the requirement on developers will simply be to make sure
>  > you run the Ant build/tests RIGHT BEFORE checking in your code (a
>  > procedure all should be following anyway). This will ensure it is in
>  > the format that the group agreed upon when you perform your checkin (FYI
>  > - only classes you have as writable will be effected).
>  >
>  > There is no mandate that any developer use the beautifier themselves.
>  > If you so choose to use a beautifier yourself, you can pick any
>  > beautifier you'd like, and create any format you like. Your changes
>  > will not be seen by the group though since the Ant script will reformat
>  > the code to the group's agreed upon format prior t you checking that
>  > code in.
>  >
>  > In case you wish to use Jalopy yourself within an IDE I will tell the
>  > group where the format file is located (and this is specific to
>  > Jalopy). You will then just need to point Jalopy to this file.
>  >
>  >
> 
>  
> 


-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wth...@ac...