From: Ryan Ackley [EMAIL PROTECTED]
I am definitely -1 on setting up a complex process with checkstyle. The
only
benefit I see of code formatting is to make the code readable with the
correct tabbing. I don't know of any other benefits because I have never
used a pretty printer. But this is
Ok, it makes sense.
Since Rainer is (correctly) concerned that he won't recognize the code after
being mand pretty, let's say what this pretty thing should do.
1. Tabs - spaces
2. Correct CR/LF
3. Reduce to 80 lines width longer lines.
Yup! Thazz about it! It will also do some other
Consider adding these features to Centipede (the build system POI uses)
or even checkstyle.
If anyone is interested enough I have a scripting challenge for you.
I'm pretty sure it can be done. Add this warning/reformat solution to
Loginfo in CVS. This script runs on checkin
Yup! Thazz about it! It will also do some other minor things like turn
if (blabla blabla)
blabla();
to
if (blabla blabla) {
blabla();
}
Arrgh! Either leave it as it is, because this is the most concise
and comprehensive way to put it or reformat it to
if (blabla blabla)
{
Discussion ended (per original announcement that the issue would be
killed if this disintegrated into a discussion on brace placement/etc).
There will be no pretty printer. We'll just have to live with ugly
code. Sorry, thanks for playing.
PedanticAndIrrelevantDiscussionException thrown at
Andrew C. Oliver [EMAIL PROTECTED] wrote:
Discussion ended (per original announcement that the issue would be
killed if this disintegrated into a discussion on brace placement/etc).
There will be no pretty printer. We'll just have to live with ugly
code. Sorry, thanks for playing.
-1 for a general and automatic reformatting. I don't like my
code to be crunched by some tool in a way I do not like. When I
write down code, I have my reasons for how I am doing it. Others
may like my style or not. I'd hate no work on source code I once
wrote and now don't recognize any
What I proposed is in between: the code is reformatted *only* if it fails
more than X number of checkstyle tests.
This way if the code you write is mainly in line, it will not be changed.
If not , it will.
This would solve your problem, since code that doesn't break (the loose
standards we
From: Rainer Klute [EMAIL PROTECTED]
What I proposed is in between: the code is reformatted *only* if it fails
more than X number of checkstyle tests.
This way if the code you write is mainly in line, it will not be changed.
If not , it will.
This would solve your problem, since code that
Nicola Ken Barozzi [EMAIL PROTECTED] wrote:
The problem is, where do we store this history?
In a special Javadoc tag for each method or class. Example:
@checkstyle-results: The following is not okay with respect to
coding standards bla bla bla...
@checkstyle-resolve-until:
Nicola Ken Barozzi [EMAIL PROTECTED] wrote:
Hmmm... what about a timeframe that is shorter the higher the errors are?
For example, if the errors are 20, it could give the user 1 month, if they
are 200, 3 days.
(maybe you can come up with a better function())
Not off hand. I'd first need some
]
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
From: Ryan Ackley [EMAIL PROTECTED]
+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.
How about our last proposal, about giving a fair warning and reformatting
AFAIK, Not really possible. Check style checks a number of pedantic
things that the formatter doesn't. (And Checkstyle is really annoying
with some of those) This would cause the formatter to run repetitively.
If CheckStyle provided its own pedantic formatter then it would
work...but it
Nicola Ken Barozzi wrote:
From: Ryan Ackley [EMAIL PROTECTED]
+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.
How about our last proposal, about giving
Subject: Re: [VOTE] http://jrefactory.sourceforge.net/cspretty.html
From: Ryan Ackley [EMAIL PROTECTED]
+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.
How
+1, so long as it is consistent, as in, one does not get loads of spurious
commits all over the codebase every night. I would be happy with one big
change, and then incremental changes based on new checkins.
Regards
-
Avik
Quoting Andrew C. Oliver [EMAIL PROTECTED]:
Hi All,
Please vote
Hi All,
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
18 matches
Mail list logo
