+1 I don't the see the problem with a one time code reformatting on check-in.
Glen raises a great point about conflicts with a cron job. So I would definitely be opposed to that. Ryan ----- Original Message ----- From: "Glen Stampoultzis" <[EMAIL PROTECTED]> To: "POI Developers List" <[EMAIL PROTECTED]> Sent: Saturday, May 11, 2002 8:15 PM Subject: Re: [VOTE] http://jrefactory.sourceforge.net/cspretty.html > -0, I think might cause merge conflicts. For example in the following > sequence: > > 1. checking some code > 2. cron job reformats. > 3. continue working on code without updating then commit changes. > bzzzt conflicts. > > so +1 for once off, -0 for frequent cron job. maybe and infrequent (2 > weekly) cron job would be okay. > > -- Glen > > > ----- Original Message ----- > From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> > To: "POI Developers List" <[EMAIL PROTECTED]> > Sent: Saturday, May 11, 2002 8:34 PM > Subject: Re: [VOTE] http://jrefactory.sourceforge.net/cspretty.html > > > > From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > > > > Please vote now or forever hold your peace. I'm consulting first > > > because after you see the big megacommit it will be too late. > > > > > > I'd like to install an automatic source formatter into the cron job that > > > does our nightly builds. > > > > > > I've picked this one http://jrefactory.sourceforge.net/cspretty.html > > > because it doesn't crash while processing any of our code (unlike jalopy > > > which was just a big pain) and after running it 3 times on our code, it > > > no longer results in different results (jalopy kept adding //End of > > > class to the end of every file EVERY TIME). > > > > > > I would be happy to work with Ken to get this into Centipede so that you > > > could format the code to your preferences when you work on it locally. > > > > +1+1+1+1+1+1+1+1+1+1=+1000 :-D > > > > > I'll merely format it using the defaults that came with jrefactory minus > > > some unarguable changes (running on unix so wanted LF not CRLF, and one > > > of the options ...don't remember... I changed to make everything work > > > right and always diff the same).. . Whining about which format settings > > > or some minute detail of the format or even beginning a stupid > > > unconcludable discussion (READ: if you don't like it reformat it locally > > > via the aforementioned build task once we get it implemented...this is > > > tooooo pedantic to argue about) hereby changes my vote to -1 on this. > > > > > > I hereby vote +1 -- consistent formatting could be nice. > > > > I'm +0 for it. > > > > But before implementing it, what about a code formatter that kiks in > *only* > > if a committed file has a number of checkstyle errors (for our standards) > > > > an certain threshold? > > > > Sometimes it's nice to give a certain indention that automatic tools don't > > do, and if the file is consistent with our standards, it's not needed to > > have it reformatted. > > > > So, I'm +1 (that means I will help) for running this tool on files that > > don't pass the checkstyle check to a certain threshold. > > > > Oh, and be careful that CSPretty can be made to add javadocs > automatically. > > This needs to be avoided because checkstyle won't complain but the > javadocs > > would still be useless. > > > > What do you think? > > > > -- > > Nicola Ken Barozzi [EMAIL PROTECTED] > > - verba volant, scripta manent - > > (discussions get forgotten, just code remains) > > --------------------------------------------------------------------- > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
