You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <te...@gmail.com> on 2006/01/18 03:00:55 UTC
Re: Checkstyle (was svn commit: r360442 [1/3] )
Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?
I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.
For more, see
* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.
-Ted.
On 12/31/05, Ted Husted <te...@gmail.com> wrote:
> See also
>
>
> for more on this.
>
> On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
> > Author: husted
> > Date: Sat Dec 31 12:10:04 2005
> > New Revision: 360442
> >
> > URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
> > Log:
> > Code reformatting only. No functional changes.
> > * Used JetBrains IDEA 5.x to conform code format per our guidelines.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Wendy Smoak wrote:
> Frank W. Zammetti <fz...@omnytex.com> wrote:
>> I haven't been able to get Jalopy to cooperate in the least. A big part
>> of it is that the documentation leaves a great deal to be desired in
>> explaining how to configure it,
>
> I have the same problem with the documentation. Is the XML config
> universal, or is that only for the Maven plugin?
AFAICT, the XML config is universal... it should work for any Jalopy
plug-in in any IDE, build tool or what have you.
The other problem I faced when I was still looking at this is that there
seems to be some substantial differences in the config format from one
version of Jalopy to the next. I may be wrong about that, I could have
gotten that impression incorrectly, but it did look to be the case.
Because of this, when I finally did get one plug-in or another to
generate a baseline rules file, it didn't work with the other plug-in
because of a version difference.
> As a starting point, the default config file that comes with the Maven
> Jalopy Plugin is here:
> http://svn.apache.org/repos/asf/struts/build/trunk/jalopy_struts.xml
At one point I think you pointed me at that (or I found it on my own)
and I tried to use it as a baseline... that's when Jalopy didn't seem to
be making changes that it should have (or that I at least *thought* it
should be making) and that's when I kind of gave up on it... that was
also about the time it was starting to sound like everyone was happy
with letting IDEA do it anyway, so I didn't explore this any further.
> Wendy
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
On 2/5/06, Ted Husted <te...@gmail.com> wrote:
>
> OK, I'll make a point of running Jalopy before checkins, to avoid any
> flip-flopping.
Sounds good, assuming it can be configured so it doesn't introduce new
problems. Or, in my case, to to run at all:
/svn/struts/current/action
$ maven jalopy
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
java.lang.ClassCastException: java.lang.String
at de.hunsicker.jalopy.storage.Convention.synchronize(Convention.java:2419)
...
BUILD FAILED
File...... c:\java\m1-repository\cache\maven-jalopy-plugin-1.3.1\plugin.jelly
Element... ant:jalopy
Line...... 64
Column.... 46
java.lang.NoClassDefFoundError
Total time: 2 seconds
Finished at: Sun Feb 05 12:03:18 MST 2006
I have *no* idea what I did to it. I've been switching versions of
other plugins, but not this one, and re-installing everything didn't
fix it. I'm setting this aside for now; maybe it will start working
again as mysteriously as it stopped.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 2/5/06, Wendy Smoak <ws...@gmail.com> wrote:
> If IDEA is going to be a one time thing, and Jalopy is to be made part
> of the build, then IDEA probably needs to be run before Jalopy, even
> if that means fewer complaints get fixed.
OK, I'll make a point of running Jalopy before checkins, to avoid any
flip-flopping.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 2/5/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Wendy Smoak wrote:
> > Besides IDEA and Jalopy, are there any other code formatting tools we
> > should be considering? We're so close to the Sun code conventions, it
> > seems like this shouldn't be so hard to do.
>
> None that I'm aware of. I just spent a few minutes looking around, but
> what I found are all very early in development or are not free. Jalopy
> would seem, at least after a cursory bit of research, to be the only
> really viable option.
Once we get past what IDEA and Jalopy fix, most of the remaining
changes are not mechanical, such as missing Javadocs.
We might be able to fix these over time. For example, if we need to
work on a class, people might be able to take a few extra minutes to
fix the legacy checkstyle errors too.
I think people might be liable to do this if we can nix the mechanical
errors and put the codebase into a uniform state.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Wendy Smoak wrote:
> Frank: The JEdit plugin was able to import the jalopy_struts.xml file
> that I checked into current/build, and export a version with changes.
> The Maven plugin uses Jalopy 1.0b11, and the JEdit plugin uses 1.0b7,
> which seems to be close enough.
Cool, yeah, seems like it would be close enough. I'd hope so anyway!
Weird though... I'm trying to export from the jEdit plug-in... I figure
that should give me a base file, but it's outputting gibberish. I have
to run some errands, I'll try again when I get home.
> This might help, though it's probably for the upcoming 1.5 version:
> https://sourceforge.net/forum/forum.php?thread_id=1405105&forum_id=148156
>
> Besides IDEA and Jalopy, are there any other code formatting tools we
> should be considering? We're so close to the Sun code conventions, it
> seems like this shouldn't be so hard to do.
None that I'm aware of. I just spent a few minutes looking around, but
what I found are all very early in development or are not free. Jalopy
would seem, at least after a cursory bit of research, to be the only
really viable option.
> Thanks,
> --
> Wendy
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
If we are going to use code reformatting tools like Jalopy, then
perhaps we do not need Checkstyle to vet mechanical problems, like
line-length. If we set Jalopy to seek an 80 character line length, we
could set CheckStyle for, say, 120, to give us some leeway for lines
that are hard for Jalopy to wrap.
As to the styles like
} else {
versus
}
else {
personally, I can't say I very much care. If Jalopy wants to wrap it
that way, that's fine with me. So long as the style is reasonable and
consistent, I'm a happy camper.
If we take LineLength, Whitespace, and the Curlies out of the
equation, then we are down to 1603 checkstyles errors in Action, that
seem to describe errors we actually deserve!
* http://people.apache.org/~husted/checkstyle/checkstyle-report.html
There are a couple of missing headers, but the rest seem to be true
bad practices, like magic numbers and missing Javadocs.
I would suggest that a reasonable goal would be to use Jalopy to
correct mechanical errors, like line length, and let CheckStyle focus
on eeper coding problems that something like Jalopy can't fix.
I've updated the default checkstyle configuraton to match what I used
to achieve the referenced report and the current state of the
Action/Action package. If this seems all right, I could conform the
JavaDocs on the rest of the Acton subproject, and move on to the
others.
One note: In the checkstyle configuration, I also disabled the check
for Inline conditions. I myself don't find this construct hard to
read, and some of us have tended to use Inline Conditionals over the
years.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
On 2/5/06, Wendy Smoak <ws...@gmail.com> wrote:
> The long lines are a problem. Not fixing them is one thing, but it
> wants to make this change, which *creates* a line longer than 80
> characters:
>
> - protected String processorClass =
> - "org.apache.struts.chain.ComposableRequestProcessor";
> + protected String processorClass =
> "org.apache.struts.chain.ComposableRequestProcessor";
>From the sf.net forum:
"Preferences->printer->wrapping->wrap after assignments (make sure
this is checked)"
I'm not using the GUI, but that was enough of a hint, and r375446
seems to have helped.
But Jalopy is still insisting on long lines for method declarations,
such as (in ActionForm):
public ActionErrors validate(ActionMapping mapping, ServletRequest
request) {
and for method calls (in ActionRedirect):
result.append("parameterString=").append(getParameterString()).append("]");
(though that one could just as well be split into two lines.)
It also makes this change:
- } else {
+ }
+ else {
which causes Checkstyle to complain that '} should be on the same line'.
Patches for the config file (build/jalopy_struts.xml) are welcome!
I'm testing with 'maven jalopy' in struts-action. Since it was
already reformatted, it's easy to see (with 'svn diff') where Jalopy
is making changes that it shouldn't.
Thanks,
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
On 2/5/06, Ted Husted <te...@gmail.com> wrote:
> I'd be happy to fix the Javadoc issues. It's mainly a matter of
> inserting a blank line before using exotic elements, like an unordered
> list.
Okay. :)
> The main use of IDEA in this case is to redress past errors. Once we
> are over this hump, just running the Jalopy task and watching the
> Checkstyle reports should be enough. The major style check that Jalopy
> is not fixing is long lines.
If IDEA is going to be a one time thing, and Jalopy is to be made part
of the build, then IDEA probably needs to be run before Jalopy, even
if that means fewer complaints get fixed. Right now, Jalopy wants to
make additional changes in struts-action, such as:
protected ForwardConfig execute(ActionContext context, Action action,
- ActionConfig actionConfig,
- ActionForm actionForm)
- throws Exception {
+ ActionConfig actionConfig, ActionForm actionForm)
+ throws Exception {
ServletActionContext saContext = (ServletActionContext) context;
That's just indentation and wrapping, but which one is correct, and
which setting controls it?
The long lines are a problem. Not fixing them is one thing, but it
wants to make this change, which *creates* a line longer than 80
characters:
- protected String processorClass =
- "org.apache.struts.chain.ComposableRequestProcessor";
+ protected String processorClass =
"org.apache.struts.chain.ComposableRequestProcessor";
I've asked on the Jalopy sf.net forum, but it isn't very active.
Google turned up this post which might be the config that Forrest is using:
http://www.nabble.com/Re:-Automated-formatting-of-Java-files-p712099.html
Frank: The JEdit plugin was able to import the jalopy_struts.xml file
that I checked into current/build, and export a version with changes.
The Maven plugin uses Jalopy 1.0b11, and the JEdit plugin uses 1.0b7,
which seems to be close enough.
This might help, though it's probably for the upcoming 1.5 version:
https://sourceforge.net/forum/forum.php?thread_id=1405105&forum_id=148156
Besides IDEA and Jalopy, are there any other code formatting tools we
should be considering? We're so close to the Sun code conventions, it
seems like this shouldn't be so hard to do.
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 2/5/06, Wendy Smoak <ws...@gmail.com> wrote:
> I'm not so sure about IDEA-- it did fix additional complaints, but I'm
> inclined to blame it for the more unpopular changes like reformatting
> the Javadoc into 'paragraphs' regardless of markup.
I'd be happy to fix the Javadoc issues. It's mainly a matter of
inserting a blank line before using exotic elements, like an unordered
list.
The main use of IDEA in this case is to redress past errors. Once we
are over this hump, just running the Jalopy task and watching the
Checkstyle reports should be enough. The major style check that Jalopy
is not fixing is long lines.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
Frank W. Zammetti <fz...@omnytex.com> wrote:
> I haven't been able to get Jalopy to cooperate in the least. A big part
> of it is that the documentation leaves a great deal to be desired in
> explaining how to configure it,
I have the same problem with the documentation. Is the XML config
universal, or is that only for the Maven plugin?
As a starting point, the default config file that comes with the Maven
Jalopy Plugin is here:
http://svn.apache.org/repos/asf/struts/build/trunk/jalopy_struts.xml
Ted wrote:
> My suggestion is to run the automatic reformatting toolds on the
> remaining Action Library subproject, wrap up the notes, and call it a
> release.
Jalopy's changes look okay from here, but I need help making sure that
it conforms to our modified Checkstyle rules. I'll post some diffs
for review tomorrow.
I'm not so sure about IDEA-- it did fix additional complaints, but I'm
inclined to blame it for the more unpopular changes like reformatting
the Javadoc into 'paragraphs' regardless of markup.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, January 19, 2006 9:03 am, Ted Husted said:
> On 1/19/06, Wendy Smoak <ws...@gmail.com> wrote:
>> FWIW, the Maven 1 plugin worked fine. (Worked as in 'reformatted the
>> struts-action code, and it still compiled afterwards.')
>
> Did you have a chance to peek at the CheckStyle report? For Action
> right now, we're seeing a brutal 4733 errors in 281 files.
I started having a suspicion towards the end last night that Jalopy was
not dealing with some things that it should have been. For instance, I
was looking at one specific line in o.a.s.action.Action.java (188) that is
longer than 80 characters and should have been wrapped, didn't have
anything odd about it that would keep it from being wrapped, and yet
Jalopy just wouldn't seem to wrap it. I don't have any idea why this
might be the case unfortunately, but I wouldn't be surprised is the Maven
plug-in was doing the same thing... and the exception your seeing I have
no idea about, I know it works from Ant :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
The code reformatting tools took care of about half of the the
Checkstyle errors, but that is still going to leave a thousand or two
per subproject. Most of the remaining errors are Javadoc oversights
and other non-functional issues.
Overall, addressing the remaining errors is taking me at least an hour
per 100 errors. Since we have several thousand errors, there doesn't
seem to be enough cost:benefit to addresss the manual errors for the
1.3.0 release.
My suggestion is to run the automatic reformatting toolds on the
remaining Action Library subproject, wrap up the notes, and call it a
release.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Actually, someone pointed out to me off-list that FindBugs is in the
Maven repository... I was confused, JLint is the native app that
requires some setup. I was confusing the two. Of course, now I have
*NO* idea why I stopped using FindBugs, I'll have to go play a bit
tonight :)
Frank
Frank W. Zammetti wrote:
> Agreed, and for a while I was in fact using it... I think the only real
> reason I stopped is because I couldn't figure out how to make it work
> from Ant *without* having to first install it (concerns about
> portability for new developers). Your absolutely right though, it's
> excellent. JLint is another that I was using for a while, and similarly
> it finds real honest-to-goodness problems that the others don't.
>
> Frank
>
> Martin Cooper wrote:
>>
>>
>> On 1/20/06, *Frank W. Zammetti* <fzlists@omnytex.com
>> <ma...@omnytex.com>> wrote:
>>
>> ...but I think what's more important to note is that Checkstyle
>> doesn't
>> just catch simple formatting problems, it catches code smells and
>> things
>> that can cause subtle problems
>>
>> The kinds of things I'm talking about are covered by rules like
>> DefaultComesLast, FallThrough, HiddenField, IllegalCatch,
>> InnerAssignment, MagicNumber, NestedIfDepth, ParameterAssignment,
>> ReturnCount and ThisParameter. And that doesn't even mention all the
>> rules pertaining to metrics, which usually uncover places that can
>> and
>> probably should be refactored.
>>
>> I wish I could find it now (Google isn't turning it up), but a while
>> back I saw an analysis of various projects that correlated Checkstyle
>> complaints to reported bugs in a project. Now, I'm usually of the
>> "lies, damn lies and statistics" mentality, but the apparent
>> correlation
>> was plain to see. My own experience bears out the conclusion of that
>> report.
>>
>> Plus, there is something to be said for code that is consistently
>> formatted in terms of being able to comprehend it. The less your
>> brain
>> has to switch gears looking at different coding styles, the
>> better. It
>> doesn't matter what style you implement, as long as there is
>> consistency.
>>
>> In my mind, code with as few Checkstyle complaints as possible is
>> better
>> code without question. At work I actually require all code have no
>> Checkstyle *OR* PMD complaints before it can be deployed to
>> production,
>>
>> You should add FindBugs to that list. It finds real, serious bugs that
>> the other two don't. We use all three tools at my day job, to good
>> effect.
>>
>> --
>> Martin Cooper
>>
>>
>> and I've noticed a marked reduction in "simple" bugs, i.e., those
>> that
>> generally aren't a big deal to fix and maybe will never cause any
>> real
>> problems but which can build up over time and ultimately just make
>> code
>> more difficult to maintain. I view it as more than a "broken
>> windows"
>> kind of thing :) In fact, I personally put quite a bit of
>> importance in
>> it (as I would a broken window in my house, but I digress - LOL)
>>
>> Frank
>>
>> Don Brown wrote:
>> > I think it is more of a "broken windows" kind of thing. For a
>> long
>> > time, we've ignored Checkstyle but recently, there has been some
>> concern
>> > that we not let our code degenerate, at least regards to
>> formatting.
>> > These types of issues usually come up around release time.
>> >
>> > Don
>> >
>> > Patrick Lightbody wrote:
>> >> Just curious: what is the motivation for the checkstyle process
>> in the
>> >> first place? Code standards can be important, but usually it
>> isn't my
>> >> top concern. Is there some Apache requirement that the checkstyle
>> >> process run?
>> >>
>> ---------------------------------------------------------------------
>> >> Posted via Jive Forums
>> >>
>>
>> http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
>>
>>
>> <http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811>
>>
>> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> <ma...@struts.apache.org>
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> <ma...@struts.apache.org>
>> >>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> <ma...@struts.apache.org>
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> <ma...@struts.apache.org>
>> >
>> >
>> >
>> >
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM: fzammetti
>> Yahoo: fzammetti
>> MSN: fzammetti@hotmail.com <ma...@hotmail.com>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> <ma...@struts.apache.org>
>> For additional commands, e-mail: dev-help@struts.apache.org
>> <ma...@struts.apache.org>
>>
>>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Agreed, and for a while I was in fact using it... I think the only real
reason I stopped is because I couldn't figure out how to make it work
from Ant *without* having to first install it (concerns about
portability for new developers). Your absolutely right though, it's
excellent. JLint is another that I was using for a while, and similarly
it finds real honest-to-goodness problems that the others don't.
Frank
Martin Cooper wrote:
>
>
> On 1/20/06, *Frank W. Zammetti* <fzlists@omnytex.com
> <ma...@omnytex.com>> wrote:
>
> ...but I think what's more important to note is that Checkstyle doesn't
> just catch simple formatting problems, it catches code smells and things
> that can cause subtle problems
>
> The kinds of things I'm talking about are covered by rules like
> DefaultComesLast, FallThrough, HiddenField, IllegalCatch,
> InnerAssignment, MagicNumber, NestedIfDepth, ParameterAssignment,
> ReturnCount and ThisParameter. And that doesn't even mention all the
> rules pertaining to metrics, which usually uncover places that can and
> probably should be refactored.
>
> I wish I could find it now (Google isn't turning it up), but a while
> back I saw an analysis of various projects that correlated Checkstyle
> complaints to reported bugs in a project. Now, I'm usually of the
> "lies, damn lies and statistics" mentality, but the apparent correlation
> was plain to see. My own experience bears out the conclusion of that
> report.
>
> Plus, there is something to be said for code that is consistently
> formatted in terms of being able to comprehend it. The less your brain
> has to switch gears looking at different coding styles, the better. It
> doesn't matter what style you implement, as long as there is
> consistency.
>
> In my mind, code with as few Checkstyle complaints as possible is better
> code without question. At work I actually require all code have no
> Checkstyle *OR* PMD complaints before it can be deployed to production,
>
>
> You should add FindBugs to that list. It finds real, serious bugs that
> the other two don't. We use all three tools at my day job, to good effect.
>
> --
> Martin Cooper
>
>
> and I've noticed a marked reduction in "simple" bugs, i.e., those that
> generally aren't a big deal to fix and maybe will never cause any real
> problems but which can build up over time and ultimately just make code
> more difficult to maintain. I view it as more than a "broken windows"
> kind of thing :) In fact, I personally put quite a bit of importance in
> it (as I would a broken window in my house, but I digress - LOL)
>
> Frank
>
> Don Brown wrote:
> > I think it is more of a "broken windows" kind of thing. For a long
> > time, we've ignored Checkstyle but recently, there has been some
> concern
> > that we not let our code degenerate, at least regards to formatting.
> > These types of issues usually come up around release time.
> >
> > Don
> >
> > Patrick Lightbody wrote:
> >> Just curious: what is the motivation for the checkstyle process
> in the
> >> first place? Code standards can be important, but usually it
> isn't my
> >> top concern. Is there some Apache requirement that the checkstyle
> >> process run?
> >>
> ---------------------------------------------------------------------
> >> Posted via Jive Forums
> >>
> http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
> <http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> <ma...@struts.apache.org>
> >> For additional commands, e-mail: dev-help@struts.apache.org
> <ma...@struts.apache.org>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> <ma...@struts.apache.org>
> > For additional commands, e-mail: dev-help@struts.apache.org
> <ma...@struts.apache.org>
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com <ma...@hotmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> <ma...@struts.apache.org>
> For additional commands, e-mail: dev-help@struts.apache.org
> <ma...@struts.apache.org>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Martin Cooper <ma...@apache.org>.
On 1/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> ...but I think what's more important to note is that Checkstyle doesn't
> just catch simple formatting problems, it catches code smells and things
> that can cause subtle problems
>
> The kinds of things I'm talking about are covered by rules like
> DefaultComesLast, FallThrough, HiddenField, IllegalCatch,
> InnerAssignment, MagicNumber, NestedIfDepth, ParameterAssignment,
> ReturnCount and ThisParameter. And that doesn't even mention all the
> rules pertaining to metrics, which usually uncover places that can and
> probably should be refactored.
>
> I wish I could find it now (Google isn't turning it up), but a while
> back I saw an analysis of various projects that correlated Checkstyle
> complaints to reported bugs in a project. Now, I'm usually of the
> "lies, damn lies and statistics" mentality, but the apparent correlation
> was plain to see. My own experience bears out the conclusion of that
> report.
>
> Plus, there is something to be said for code that is consistently
> formatted in terms of being able to comprehend it. The less your brain
> has to switch gears looking at different coding styles, the better. It
> doesn't matter what style you implement, as long as there is consistency.
>
> In my mind, code with as few Checkstyle complaints as possible is better
> code without question. At work I actually require all code have no
> Checkstyle *OR* PMD complaints before it can be deployed to production,
You should add FindBugs to that list. It finds real, serious bugs that the
other two don't. We use all three tools at my day job, to good effect.
--
Martin Cooper
and I've noticed a marked reduction in "simple" bugs, i.e., those that
> generally aren't a big deal to fix and maybe will never cause any real
> problems but which can build up over time and ultimately just make code
> more difficult to maintain. I view it as more than a "broken windows"
> kind of thing :) In fact, I personally put quite a bit of importance in
> it (as I would a broken window in my house, but I digress - LOL)
>
> Frank
>
> Don Brown wrote:
> > I think it is more of a "broken windows" kind of thing. For a long
> > time, we've ignored Checkstyle but recently, there has been some concern
> > that we not let our code degenerate, at least regards to formatting.
> > These types of issues usually come up around release time.
> >
> > Don
> >
> > Patrick Lightbody wrote:
> >> Just curious: what is the motivation for the checkstyle process in the
> >> first place? Code standards can be important, but usually it isn't my
> >> top concern. Is there some Apache requirement that the checkstyle
> >> process run?
> >> ---------------------------------------------------------------------
> >> Posted via Jive Forums
> >>
> http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Patrick Lightbody <fo...@opensymphony.com>.
Good point. Those are very helpful. If you use IDEA 5, it highlight most of those things as well in the editor, which is really nice.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=30057#30057
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
...but I think what's more important to note is that Checkstyle doesn't
just catch simple formatting problems, it catches code smells and things
that can cause subtle problems
The kinds of things I'm talking about are covered by rules like
DefaultComesLast, FallThrough, HiddenField, IllegalCatch,
InnerAssignment, MagicNumber, NestedIfDepth, ParameterAssignment,
ReturnCount and ThisParameter. And that doesn't even mention all the
rules pertaining to metrics, which usually uncover places that can and
probably should be refactored.
I wish I could find it now (Google isn't turning it up), but a while
back I saw an analysis of various projects that correlated Checkstyle
complaints to reported bugs in a project. Now, I'm usually of the
"lies, damn lies and statistics" mentality, but the apparent correlation
was plain to see. My own experience bears out the conclusion of that
report.
Plus, there is something to be said for code that is consistently
formatted in terms of being able to comprehend it. The less your brain
has to switch gears looking at different coding styles, the better. It
doesn't matter what style you implement, as long as there is consistency.
In my mind, code with as few Checkstyle complaints as possible is better
code without question. At work I actually require all code have no
Checkstyle *OR* PMD complaints before it can be deployed to production,
and I've noticed a marked reduction in "simple" bugs, i.e., those that
generally aren't a big deal to fix and maybe will never cause any real
problems but which can build up over time and ultimately just make code
more difficult to maintain. I view it as more than a "broken windows"
kind of thing :) In fact, I personally put quite a bit of importance in
it (as I would a broken window in my house, but I digress - LOL)
Frank
Don Brown wrote:
> I think it is more of a "broken windows" kind of thing. For a long
> time, we've ignored Checkstyle but recently, there has been some concern
> that we not let our code degenerate, at least regards to formatting.
> These types of issues usually come up around release time.
>
> Don
>
> Patrick Lightbody wrote:
>> Just curious: what is the motivation for the checkstyle process in the
>> first place? Code standards can be important, but usually it isn't my
>> top concern. Is there some Apache requirement that the checkstyle
>> process run?
>> ---------------------------------------------------------------------
>> Posted via Jive Forums
>> http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Don Brown <mr...@twdata.org>.
I think it is more of a "broken windows" kind of thing. For a long time, we've ignored Checkstyle but recently, there
has been some concern that we not let our code degenerate, at least regards to formatting. These types of issues
usually come up around release time.
Don
Patrick Lightbody wrote:
> Just curious: what is the motivation for the checkstyle process in the first place? Code standards can be important, but usually it isn't my top concern. Is there some Apache requirement that the checkstyle process run?
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Patrick Lightbody <fo...@opensymphony.com>.
Just curious: what is the motivation for the checkstyle process in the first place? Code standards can be important, but usually it isn't my top concern. Is there some Apache requirement that the checkstyle process run?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29811#29811
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 1/20/06, Patrick Lightbody <fo...@opensymphony.com> wrote:
> I think asking developers to run _two_ tasks on every check-in is a bit much. Perhaps we
> can set up a process where we just do that every X weeks, or the end of the month?
Most of us use the Maven build, if not to build the project, then to
build the website. If we tack Jalopy onto that, the next person to run
the Maven build would catch any straggling style issues. (Or at least
those that Jalopy catches.)
We're not asking anyone to run any process that they don't want to
run. The only suggestion is that we need to eliminate the CheckStyle
errors. Jalopy and IDEA are just one way we can do that.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Patrick Lightbody <fo...@opensymphony.com>.
We had good luck with Jalopy, though sometimes it would touch files that it didn't need to. Overall we've had good not being too formal with the style and then once in a while (maybe 3-6 months) someone would run the IDEA reformat on the entire codebase.
I think the important theme should be to minimize how much work developers are required to do. From day-to-day development, I tend to not use maven/ant builds. So I think it is important to me to either:
1) Use a code style I am used to ;)
2) Configure IDEA to format the code on check-in.
I think asking developers to run _two_ tasks on every check-in is a bit much. Perhaps we can set up a process where we just do that every X weeks, or the end of the month?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14802&messageID=29756#29756
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 1/19/06, Wendy Smoak <ws...@gmail.com> wrote:
> Try reverting to version 1.3.1 of the plugin
OK, that worked just fine, and I can run Jalopy as a Maven task.
Of course, as Frank reported, Jalopy is not reformatting everything it
could, especialy long lines.
I tried reformatting the Action subproject with Jalopy, IDEA, and then
combinations of the two. Here's the skinny:
Action CheckStyle Errors
4887 Status Quo
2677 Jalopy
2483 IDEA + Jalopy
2100 IDEA
2033 Jalopy + IDEA
The Status Quo report is here
* http://struts.apache.org/struts-action/checkstyle-report.html
The trial reports are here:
* http://people.apache.org/~husted/checkstyle/
If the goal is to reduce CheckStyle errors to zero, running Jalopy and
then IDEA seems to be the best starting point. Once the codebase is
back up to snuff, I expect Jalopy (and a vigilant PMC) will be
sufficient.
For each subproject, starting with the Action Library, my intention would be to
* Reformat using our IDEA settings; check-in
* Address non-functional errors manually (Javadoc comments and such); check-in
* Address functional errors (non-encapsulated fields and such); check-in
and see how close we can come to zero Checkstyle errors in a
reasonable amount of time.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/19/06, Ted Husted <te...@gmail.com> wrote:
> Did you have a chance to peek at the CheckStyle report? For Action
> right now, we're seeing a brutal 4733 errors in 281 files.
It dropped to 2810 errors in 281files, but I didn't look closely at
what it changed.
> Did you do anything else besides this, Wendy. Against a fresh
> checkout, freshly built, I tried installing the plugin and running the
> jalopy:format and jalopy targets, but a dependency seems to be
> missing: Here's the screen history:
Sorry, I ran 'maven jalopy' (which worked) before upgrading to the
latest. Version 1.4 doesn't work for me, either. (It might be a
Maven 1.1 plugin, though the release notes don't say that.)
Try reverting to version 1.3.1 of the plugin which must have been
bundled with Maven 1:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven
-DartifactId=maven-jalopy-plugin
-Dversion=1.3.1
If that works we can declare it in project.xml to make sure everyone
is on the same version.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 1/19/06, Wendy Smoak <ws...@gmail.com> wrote:
> FWIW, the Maven 1 plugin worked fine. (Worked as in 'reformatted the
> struts-action code, and it still compiled afterwards.')
Did you have a chance to peek at the CheckStyle report? For Action
right now, we're seeing a brutal 4733 errors in 281 files.
> http://maven.apache.org/maven-1.x/reference/plugins/jalopy
>
> To install the latest:
>
> maven plugin:download
> -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
> -DgroupId=maven
> -DartifactId=maven-jalopy-plugin
> -Dversion=1.4
>
> The default config file for it is here:
> <http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/jalopy/src/plugin-resources/jalopy_maven.xml>
> (Assuming it hasn't changed since the release.)
>
> Set the maven.jalopy.style property to the new config file. The
> project.xml file indicates that this is based on Jalopy 1.5b5.
Did you do anything else besides this, Wendy. Against a fresh
checkout, freshly built, I tried installing the plugin and running the
jalopy:format and jalopy targets, but a dependency seems to be
missing: Here's the screen history:
----
E:\projects\current\build>maven plugin:download -Dmaven.repo.remote=http://www.i
biblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=
maven-jalopy-plugin -Dversion=1.4
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
build:start:
plugin:download-artifact:
[mkdir] Created dir: C:\Documents and Settings\ted_2\.maven\repository\maven
\plugins
[echo] repo is 'http://www.ibiblio.org/maven'
[echo] trying to download http://www.ibiblio.org/maven/maven/plugins/maven-j
alopy-plugin-1.4.jar
11K downloaded
plugin:download:
[delete] Deleting 1 files from C:\Program Files\Apache Software Foundation\M
aven 1.0.2\plugins
[delete] C:\Documents and Settings\ted_2\.maven\plugins not found.
[delete] Deleting 8 files from C:\Documents and Settings\ted_2\.maven\cache
[delete] Deleted 3 directories from C:\Documents and Settings\ted_2\.maven\c
ache
[copy] Copying 1 file to C:\Program Files\Apache Software Foundation\Maven 1
.0.2\plugins
BUILD SUCCESSFUL
Total time: 6 seconds
Finished at: Thu Jan 19 08:50:14 EST 2006
E:\projects\current\build>cd ..\action
E:\projects\current\action>maven jalopy:format
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
plugin maven-jalopy-plugin-1.3.1 is cached (goal) but no longer present
Cache invalidated due to out of date plugins
Attempting to download jalopy-1.5b5.jar.
1292K downloaded
Attempting to download jalopy-ant-0.1-1.5b5.jar.
12K downloaded
Attempting to download aelfred-1.2.jar.
25K downloaded
Attempting to download log4j-1.2.12.jar.
349K downloaded
Attempting to download textarea-2.2.3.jar.
65K downloaded
build:start:
jalopy:taskdef:
java:prepare-filesystem:
java:compile:
[echo] Compiling to E:\projects\current\action/target/classes
jalopy:format:
[jalopy] Jalopy Java Source Code Formatter 1.0.0
[jalopy] [ERROR] ???:0:0: ClassNotFoundException: de.hunsicker.jalopy.langua
ge.ExtendedToken
???:0:0: ClassNotFoundException: de.hunsicker.jalopy.language.ExtendedToken
[jalopy] [ERROR] ???:0:0: java.lang.NullPointerException
???:0:0: java.lang.NullPointerException
[jalopy] [ERROR] ???:0:0: ClassNotFoundException: de.hunsicker.jalopy.langua
ge.ExtendedToken
???:0:0: ClassNotFoundException: de.hunsicker.jalopy.language.ExtendedToken
[jalopy] Format 133 source files
[jalopy] E:\projects\current\action\src\java\org\apache\struts\action\Action
.java:0:0: Parse
E:\projects\current\action\src\java\org\apache\struts\action\Action.java:0:0: Pa
rse
java.lang.NullPointerException
<snip/>
BUILD FAILED
File...... C:\Documents and Settings\ted_2\.maven\cache\maven-jalopy-plugin-1.4\
plugin.jelly
Element... ant:jalopy
Line...... 64
Column.... 46
Error formatting file
Total time: 17 seconds
Finished at: Thu Jan 19 08:51:59 EST 2006
E:\projects\current\action>
----
I tried again using just "jalopy" as the goal, and running
"jalopy:taskdef" first, but with the same result.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Thanks Wendy, the conventions file you referenced is what I needed,
assuming it is just the defaults that Jalopy has built-in, which is
apparently the Sun coding standards. I can try this when I get home, if
nothing else it should give be a known valid conventions file to start
with.
I doubt I'll mess with the Maven plug-in, I'll leave that for you and/or
others. The way I was playing with it last night was using the Ant task
and my quick hacked-together script. It shouldn't ultimately matter, as
long as the conventions match the Checkstyle rules it should work from
Ant, Maven, manually, an IDE plug-in, etc.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
On Thu, January 19, 2006 7:31 am, Wendy Smoak said:
> On 1/18/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>> If anyone reading this can get the GUI configurator to spit out a
>> conventions file (using Jalopy 1.5rc1) and send it to me, I'd appreciate
>> it greatly! The default settings are actually the Sun coding standards,
>> which the Checkstyle file is set up to use with only minor alterations,
>> so in theory they should be almost perfectly matched without doing
>> anything else.
>
> FWIW, the Maven 1 plugin worked fine. (Worked as in 'reformatted the
> struts-action code, and it still compiled afterwards.')
>
> http://maven.apache.org/maven-1.x/reference/plugins/jalopy
>
> To install the latest:
>
> maven plugin:download
> -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
> -DgroupId=maven
> -DartifactId=maven-jalopy-plugin
> -Dversion=1.4
>
> The default config file for it is here:
> <http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/jalopy/src/plugin-resources/jalopy_maven.xml>
> (Assuming it hasn't changed since the release.)
>
> Set the maven.jalopy.style property to the new config file. The
> project.xml file indicates that this is based on Jalopy 1.5b5.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/18/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> If anyone reading this can get the GUI configurator to spit out a
> conventions file (using Jalopy 1.5rc1) and send it to me, I'd appreciate
> it greatly! The default settings are actually the Sun coding standards,
> which the Checkstyle file is set up to use with only minor alterations,
> so in theory they should be almost perfectly matched without doing
> anything else.
FWIW, the Maven 1 plugin worked fine. (Worked as in 'reformatted the
struts-action code, and it still compiled afterwards.')
http://maven.apache.org/maven-1.x/reference/plugins/jalopy
To install the latest:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven
-DartifactId=maven-jalopy-plugin
-Dversion=1.4
The default config file for it is here:
<http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/jalopy/src/plugin-resources/jalopy_maven.xml>
(Assuming it hasn't changed since the release.)
Set the maven.jalopy.style property to the new config file. The
project.xml file indicates that this is based on Jalopy 1.5b5.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
AARRGGHH!!
I haven't been able to get Jalopy to cooperate in the least. A big part
of it is that the documentation leaves a great deal to be desired in
explaining how to configure it, and naturally the GUI configuration
tool, which seems to be the only method talked about anywhere, doesn't
seem to be working for me. I even tried configuring it via jEdit and
IDEA plug-ins, and neither seems to want to export the setting properly
(there may be a version mismatch there, I'm pretty certain that's the
case with the jEdit plug-in).
I *thought* I had managed to get a conventions file put together
manually, but it wasn't fixing some very trivial things like line length
problems (even though when I loaded the same source file in the IDEA
plug-in config editor I could see that it would in fact fix it).
I'm calling it a night, this has been frustrating me for the better (or
more precisely, WORSE) part of three hours. I'll try again next chance
I get.
If anyone reading this can get the GUI configurator to spit out a
conventions file (using Jalopy 1.5rc1) and send it to me, I'd appreciate
it greatly! The default settings are actually the Sun coding standards,
which the Checkstyle file is set up to use with only minor alterations,
so in theory they should be almost perfectly matched without doing
anything else.
Frank
Frank W. Zammetti wrote:
> You may want to have a look at Jalopy:
>
> jalopy.sf.net
>
> There are plugins for various IDEs and editors, as well as an Ant task
> (IIRC, you can use Ant tasks from Maven?). It won't fix everything, but
> it will help enforce many of the more common coding standards. It
> should be possible to configure its rules to match those of CheckStyle,
> so you could then use CheckStyle to manually deal with what remains that
> Jalopy doesn't fix.
>
> Frank
>
> Don Brown wrote:
>> It just fills the errors list with checkstyle errors, that you can
>> then click on to be taken to the file and line. It was very handy for
>> cleaning up Scripting.
>>
>> Don
>>
>> Ted Husted wrote:
>>
>>> Does it actually reformat the code? Or just report on what should be
>>> reformatted?
>>>
>>> On 1/17/06, Don Brown <mr...@twdata.org> wrote:
>>>
>>>
>>>> I've been using jEdit's checkstyle plugin. I had to temporary modify
>>>> the checkstyle xml to remove those dynamic properties, but
>>>> otherwise, it
>>>> worked great.
>>>>
>>>> Don
>>>>
>>>> Ted Husted wrote:
>>>>
>>>>
>>>>> Is anyone using an automatic code reformatting tool that can read a
>>>>> CheckStyle configuration?
>>>>>
>>>>> I'd like to clean up some of the stylistic errors, but I would prefer
>>>>> that most of the reformatting be done by a proven tool. I have utter
>>>>> confidence in IDEA, but I don't know if we can perfectly align the
>>>>> settings with CheckStyle.
>>>>>
>>>>> For more, see
>>>>>
>>>>> * http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>>>>>
>>>>> Having CheckStyle standards is great, but I would rather have a
>>>>> consistent code style that we can enforce with an automatic
>>>>> reformatting tool.
>>>>>
>>>>> -Ted.
>>>>>
>>>>> On 12/31/05, Ted Husted <te...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> See also
>>>>>>
>>>>>>
>>>>>> for more on this.
>>>>>>
>>>>>> On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Author: husted
>>>>>>> Date: Sat Dec 31 12:10:04 2005
>>>>>>> New Revision: 360442
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
>>>>>>> Log:
>>>>>>> Code reformatting only. No functional changes.
>>>>>>> * Used JetBrains IDEA 5.x to conform code format per our guidelines.
>>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
To me, the question comes down to do you want to put the burden of
reformatting code (even if it amounts to a click of a button) on
committers rather than those submitting patches?
I know with JWP, I ask that anyone submitting patches follow the general
coding standards the existing code uses, as "enforced" by the CheckStyle
rules file. Yes, I would fix things myself before a commit, I would never
turn down a patch for non-compliance to formatting rules, but it's still
nice to get them in a compliant form.
It was actually put best by another JWP committer who said to me "when I
go over someones' house to play, I do my best to play by their rules, even
if all they are going to do is politely correct me".
So, do you want to be the parent that has to correct someone, or do you
want to make it as easy as possible (and universal, which is more to the
point in this case) to follow the rules? If you make IDEA *the* way to
reformat the code, your shifting the burden from anyone who wants to
contribute (and who doesn't themselves have IDEA) to the committers to do
the reformatting.
I'm not trying to be difficult, just trying to point out the consequence
of the decision, assuming it goes that way. If everyone is OK with it,
I'm certainly OK with it too as I'm not in a position to have any reason
to complain :) Hell, in fact, now I don't have to even think about code
formatting when I submit a patch, so less work for me! :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
On Wed, January 18, 2006 1:30 pm, Ted Husted said:
> On 1/18/06, Laurie Harper <la...@holoweb.net> wrote:
>> If the goal is to be able to run a tool to get checkstyle 'conformance'
>> wouldn't it be better to tailer checkstyle to a tool anyone could grab,
>> rather than tailoring it to what IDEA can do? Don't get me wrong, I love
>> IDEA and I'd be quite happy to be able to use it for this, but not
>> everyone has IDEA...
>>
>> +1 in principle, though.
>
> Jetbrains has donated licenses for the use of any and all ASF
> committers, so anyone with write privilges can indeed grab IDEA and
> use it to reformat the code on demand. Moreover, the reformatter is
> very clever and doesn't "touch" files that do not need reformatting.
> Any one can bring the codebase up to date in a matter of seconds
> (literally) and commit back on the files that needed style fixes. The
> important thing would be to continue to follow the longstanding rule
> to separate style-change commnits from code-change commits.
>
> As I understand, WebWork 2.2 is styled using the factory-default IDEA
> settings. If we want that codebase to pass CheckStyle in the future,
> eventually, we will need to conform one or the other.
>
> But, yes, I'm thinking that it might be less work to conform
> CheckStyle to IDEA than the other way around. The goal should be to
> ensure that a uniform coding style is consistently applied.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Sure, I'll give it a shot. Should even be able to get to it later tonight :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
On Wed, January 18, 2006 3:04 pm, Ted Husted said:
> On 1/18/06, Martin Cooper <ma...@apache.org> wrote:
>> I'd be much more inclined to add the Maven Jalopy plugin to an optional
>> goal.
>> Then nobody has to install anything (manually).
>
> If Jalopy works for everyone, then lets just do that then.
>
> Did you want to volunteer to setup a Jalopy configuration to match our
> CheckStyle settings, Frank?
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 1/18/06, Martin Cooper <ma...@apache.org> wrote:
> I'd be much more inclined to add the Maven Jalopy plugin to an optional goal.
> Then nobody has to install anything (manually).
If Jalopy works for everyone, then lets just do that then.
Did you want to volunteer to setup a Jalopy configuration to match our
CheckStyle settings, Frank?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Martin Cooper <ma...@apache.org>.
On 1/18/06, Ted Husted <te...@gmail.com> wrote:
>
> On 1/18/06, Laurie Harper <la...@holoweb.net> wrote:
> > If the goal is to be able to run a tool to get checkstyle 'conformance'
> > wouldn't it be better to tailer checkstyle to a tool anyone could grab,
> > rather than tailoring it to what IDEA can do? Don't get me wrong, I love
> > IDEA and I'd be quite happy to be able to use it for this, but not
> > everyone has IDEA...
> >
> > +1 in principle, though.
>
> Jetbrains has donated licenses for the use of any and all ASF
> committers, so anyone with write privilges can indeed grab IDEA and
> use it to reformat the code on demand. Moreover, the reformatter is
> very clever and doesn't "touch" files that do not need reformatting.
> Any one can bring the codebase up to date in a matter of seconds
> (literally) and commit back on the files that needed style fixes. The
> important thing would be to continue to follow the longstanding rule
> to separate style-change commnits from code-change commits.
>
> As I understand, WebWork 2.2 is styled using the factory-default IDEA
> settings. If we want that codebase to pass CheckStyle in the future,
> eventually, we will need to conform one or the other.
>
> But, yes, I'm thinking that it might be less work to conform
> CheckStyle to IDEA than the other way around. The goal should be to
> ensure that a uniform coding style is consistently applied.
We've used Checkstyle for our coding guidelines ever since I can remember.
I'm personally not in favour of changing the coding guidelines just to fit
IDEA. Maybe we _can_ all download IDEA, but that doesn't mean that we all
_want_ to install another IDE just for the sake of coding guidelines. I'd be
much more inclined to add the Maven Jalopy plugin to an optional goal. Then
nobody has to install anything (manually).
We know you love your choice of tools, Ted, and you love promoting them, but
that doesn't mean we all share your love for the same tools. ;-)
--
Martin Cooper
-Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
On 1/18/06, Laurie Harper <la...@holoweb.net> wrote:
> If the goal is to be able to run a tool to get checkstyle 'conformance'
> wouldn't it be better to tailer checkstyle to a tool anyone could grab,
> rather than tailoring it to what IDEA can do? Don't get me wrong, I love
> IDEA and I'd be quite happy to be able to use it for this, but not
> everyone has IDEA...
>
> +1 in principle, though.
Jetbrains has donated licenses for the use of any and all ASF
committers, so anyone with write privilges can indeed grab IDEA and
use it to reformat the code on demand. Moreover, the reformatter is
very clever and doesn't "touch" files that do not need reformatting.
Any one can bring the codebase up to date in a matter of seconds
(literally) and commit back on the files that needed style fixes. The
important thing would be to continue to follow the longstanding rule
to separate style-change commnits from code-change commits.
As I understand, WebWork 2.2 is styled using the factory-default IDEA
settings. If we want that codebase to pass CheckStyle in the future,
eventually, we will need to conform one or the other.
But, yes, I'm thinking that it might be less work to conform
CheckStyle to IDEA than the other way around. The goal should be to
ensure that a uniform coding style is consistently applied.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Laurie Harper <la...@holoweb.net>.
If the goal is to be able to run a tool to get checkstyle 'conformance'
wouldn't it be better to tailer checkstyle to a tool anyone could grab,
rather than tailoring it to what IDEA can do? Don't get me wrong, I love
IDEA and I'd be quite happy to be able to use it for this, but not
everyone has IDEA...
+1 in principle, though.
Ted Husted wrote:
> It's just that I don't have a lot of time right now to try and get
> IDEA or Jalopy to match our CheckStyle setup. If CheckStyle is going
> to be held up as the arbitrator of coding style, it would be nice if a
> code reformatter could reach the CheckStyle configuration directly.
>
> If anyone would like to volunteer to try and match IDEA's
> configuration with our CheckStyle file, that would be very helpful. I
> made some changes against the IDEA defaults, but apparently they are
> not quite right. I'd like to reduce the coding inconsistencies, but I
> don't want to introduce a lot of manual changes right before a
> release.
>
> The changes from the IDEA norm I've identified so far are documented
> in my comment of 12/31.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>
> Or, alternatively, we could develop a CheckStyle file to match the
> IDEA norm, and use that instead. I think the important thing is to
> have a coding style that we can enforce with an automatic tool, so as
> to not waste volunteer time on mechanical tasks.
>
> -Ted.
>
> On 1/17/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> You may want to have a look at Jalopy:
>>
>> jalopy.sf.net
>>
>> There are plugins for various IDEs and editors, as well as an Ant task
>> (IIRC, you can use Ant tasks from Maven?). It won't fix everything, but
>> it will help enforce many of the more common coding standards. It
>> should be possible to configure its rules to match those of CheckStyle,
>> so you could then use CheckStyle to manually deal with what remains that
>> Jalopy doesn't fix.
>>
>> Frank
>>
>> Don Brown wrote:
>>> It just fills the errors list with checkstyle errors, that you can then
>>> click on to be taken to the file and line. It was very handy for
>>> cleaning up Scripting.
>>>
>>> Don
>>>
>>> Ted Husted wrote:
>>>
>>>> Does it actually reformat the code? Or just report on what should be
>>>> reformatted?
>>>>
>>>> On 1/17/06, Don Brown <mr...@twdata.org> wrote:
>>>>
>>>>
>>>>> I've been using jEdit's checkstyle plugin. I had to temporary modify
>>>>> the checkstyle xml to remove those dynamic properties, but otherwise, it
>>>>> worked great.
>>>>>
>>>>> Don
>>>>>
>>>>> Ted Husted wrote:
>>>>>
>>>>>
>>>>>> Is anyone using an automatic code reformatting tool that can read a
>>>>>> CheckStyle configuration?
>>>>>>
>>>>>> I'd like to clean up some of the stylistic errors, but I would prefer
>>>>>> that most of the reformatting be done by a proven tool. I have utter
>>>>>> confidence in IDEA, but I don't know if we can perfectly align the
>>>>>> settings with CheckStyle.
>>>>>>
>>>>>> For more, see
>>>>>>
>>>>>> * http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>>>>>>
>>>>>> Having CheckStyle standards is great, but I would rather have a
>>>>>> consistent code style that we can enforce with an automatic
>>>>>> reformatting tool.
>>>>>>
>>>>>> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
It's just that I don't have a lot of time right now to try and get
IDEA or Jalopy to match our CheckStyle setup. If CheckStyle is going
to be held up as the arbitrator of coding style, it would be nice if a
code reformatter could reach the CheckStyle configuration directly.
If anyone would like to volunteer to try and match IDEA's
configuration with our CheckStyle file, that would be very helpful. I
made some changes against the IDEA defaults, but apparently they are
not quite right. I'd like to reduce the coding inconsistencies, but I
don't want to introduce a lot of manual changes right before a
release.
The changes from the IDEA norm I've identified so far are documented
in my comment of 12/31.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
Or, alternatively, we could develop a CheckStyle file to match the
IDEA norm, and use that instead. I think the important thing is to
have a coding style that we can enforce with an automatic tool, so as
to not waste volunteer time on mechanical tasks.
-Ted.
On 1/17/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> You may want to have a look at Jalopy:
>
> jalopy.sf.net
>
> There are plugins for various IDEs and editors, as well as an Ant task
> (IIRC, you can use Ant tasks from Maven?). It won't fix everything, but
> it will help enforce many of the more common coding standards. It
> should be possible to configure its rules to match those of CheckStyle,
> so you could then use CheckStyle to manually deal with what remains that
> Jalopy doesn't fix.
>
> Frank
>
> Don Brown wrote:
> > It just fills the errors list with checkstyle errors, that you can then
> > click on to be taken to the file and line. It was very handy for
> > cleaning up Scripting.
> >
> > Don
> >
> > Ted Husted wrote:
> >
> >> Does it actually reformat the code? Or just report on what should be
> >> reformatted?
> >>
> >> On 1/17/06, Don Brown <mr...@twdata.org> wrote:
> >>
> >>
> >>> I've been using jEdit's checkstyle plugin. I had to temporary modify
> >>> the checkstyle xml to remove those dynamic properties, but otherwise, it
> >>> worked great.
> >>>
> >>> Don
> >>>
> >>> Ted Husted wrote:
> >>>
> >>>
> >>>> Is anyone using an automatic code reformatting tool that can read a
> >>>> CheckStyle configuration?
> >>>>
> >>>> I'd like to clean up some of the stylistic errors, but I would prefer
> >>>> that most of the reformatting be done by a proven tool. I have utter
> >>>> confidence in IDEA, but I don't know if we can perfectly align the
> >>>> settings with CheckStyle.
> >>>>
> >>>> For more, see
> >>>>
> >>>> * http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
> >>>>
> >>>> Having CheckStyle standards is great, but I would rather have a
> >>>> consistent code style that we can enforce with an automatic
> >>>> reformatting tool.
> >>>>
> >>>> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
You may want to have a look at Jalopy:
jalopy.sf.net
There are plugins for various IDEs and editors, as well as an Ant task
(IIRC, you can use Ant tasks from Maven?). It won't fix everything, but
it will help enforce many of the more common coding standards. It
should be possible to configure its rules to match those of CheckStyle,
so you could then use CheckStyle to manually deal with what remains that
Jalopy doesn't fix.
Frank
Don Brown wrote:
> It just fills the errors list with checkstyle errors, that you can then
> click on to be taken to the file and line. It was very handy for
> cleaning up Scripting.
>
> Don
>
> Ted Husted wrote:
>
>> Does it actually reformat the code? Or just report on what should be
>> reformatted?
>>
>> On 1/17/06, Don Brown <mr...@twdata.org> wrote:
>>
>>
>>> I've been using jEdit's checkstyle plugin. I had to temporary modify
>>> the checkstyle xml to remove those dynamic properties, but otherwise, it
>>> worked great.
>>>
>>> Don
>>>
>>> Ted Husted wrote:
>>>
>>>
>>>> Is anyone using an automatic code reformatting tool that can read a
>>>> CheckStyle configuration?
>>>>
>>>> I'd like to clean up some of the stylistic errors, but I would prefer
>>>> that most of the reformatting be done by a proven tool. I have utter
>>>> confidence in IDEA, but I don't know if we can perfectly align the
>>>> settings with CheckStyle.
>>>>
>>>> For more, see
>>>>
>>>> * http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>>>>
>>>> Having CheckStyle standards is great, but I would rather have a
>>>> consistent code style that we can enforce with an automatic
>>>> reformatting tool.
>>>>
>>>> -Ted.
>>>>
>>>> On 12/31/05, Ted Husted <te...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> See also
>>>>>
>>>>>
>>>>> for more on this.
>>>>>
>>>>> On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Author: husted
>>>>>> Date: Sat Dec 31 12:10:04 2005
>>>>>> New Revision: 360442
>>>>>>
>>>>>> URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
>>>>>> Log:
>>>>>> Code reformatting only. No functional changes.
>>>>>> * Used JetBrains IDEA 5.x to conform code format per our guidelines.
>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Don Brown <mr...@twdata.org>.
It just fills the errors list with checkstyle errors, that you can then
click on to be taken to the file and line. It was very handy for
cleaning up Scripting.
Don
Ted Husted wrote:
>Does it actually reformat the code? Or just report on what should be
>reformatted?
>
>On 1/17/06, Don Brown <mr...@twdata.org> wrote:
>
>
>>I've been using jEdit's checkstyle plugin. I had to temporary modify
>>the checkstyle xml to remove those dynamic properties, but otherwise, it
>>worked great.
>>
>>Don
>>
>>Ted Husted wrote:
>>
>>
>>
>>>Is anyone using an automatic code reformatting tool that can read a
>>>CheckStyle configuration?
>>>
>>>I'd like to clean up some of the stylistic errors, but I would prefer
>>>that most of the reformatting be done by a proven tool. I have utter
>>>confidence in IDEA, but I don't know if we can perfectly align the
>>>settings with CheckStyle.
>>>
>>>For more, see
>>>
>>>* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>>>
>>>Having CheckStyle standards is great, but I would rather have a
>>>consistent code style that we can enforce with an automatic
>>>reformatting tool.
>>>
>>>-Ted.
>>>
>>>On 12/31/05, Ted Husted <te...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>>See also
>>>>
>>>>
>>>>for more on this.
>>>>
>>>>On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Author: husted
>>>>>Date: Sat Dec 31 12:10:04 2005
>>>>>New Revision: 360442
>>>>>
>>>>>URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
>>>>>Log:
>>>>>Code reformatting only. No functional changes.
>>>>>* Used JetBrains IDEA 5.x to conform code format per our guidelines.
>>>>>
>>>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Ted Husted <te...@gmail.com>.
Does it actually reformat the code? Or just report on what should be
reformatted?
On 1/17/06, Don Brown <mr...@twdata.org> wrote:
> I've been using jEdit's checkstyle plugin. I had to temporary modify
> the checkstyle xml to remove those dynamic properties, but otherwise, it
> worked great.
>
> Don
>
> Ted Husted wrote:
>
> >Is anyone using an automatic code reformatting tool that can read a
> >CheckStyle configuration?
> >
> >I'd like to clean up some of the stylistic errors, but I would prefer
> >that most of the reformatting be done by a proven tool. I have utter
> >confidence in IDEA, but I don't know if we can perfectly align the
> >settings with CheckStyle.
> >
> >For more, see
> >
> >* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
> >
> >Having CheckStyle standards is great, but I would rather have a
> >consistent code style that we can enforce with an automatic
> >reformatting tool.
> >
> >-Ted.
> >
> >On 12/31/05, Ted Husted <te...@gmail.com> wrote:
> >
> >
> >>See also
> >>
> >>
> >>for more on this.
> >>
> >>On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
> >>
> >>
> >>>Author: husted
> >>>Date: Sat Dec 31 12:10:04 2005
> >>>New Revision: 360442
> >>>
> >>>URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
> >>>Log:
> >>>Code reformatting only. No functional changes.
> >>>* Used JetBrains IDEA 5.x to conform code format per our guidelines.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Checkstyle (was svn commit: r360442 [1/3] )
Posted by Don Brown <mr...@twdata.org>.
I've been using jEdit's checkstyle plugin. I had to temporary modify
the checkstyle xml to remove those dynamic properties, but otherwise, it
worked great.
Don
Ted Husted wrote:
>Is anyone using an automatic code reformatting tool that can read a
>CheckStyle configuration?
>
>I'd like to clean up some of the stylistic errors, but I would prefer
>that most of the reformatting be done by a proven tool. I have utter
>confidence in IDEA, but I don't know if we can perfectly align the
>settings with CheckStyle.
>
>For more, see
>
>* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
>
>Having CheckStyle standards is great, but I would rather have a
>consistent code style that we can enforce with an automatic
>reformatting tool.
>
>-Ted.
>
>On 12/31/05, Ted Husted <te...@gmail.com> wrote:
>
>
>>See also
>>
>>
>>for more on this.
>>
>>On 12/31/05, husted@apache.org <hu...@apache.org> wrote:
>>
>>
>>>Author: husted
>>>Date: Sat Dec 31 12:10:04 2005
>>>New Revision: 360442
>>>
>>>URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
>>>Log:
>>>Code reformatting only. No functional changes.
>>>* Used JetBrains IDEA 5.x to conform code format per our guidelines.
>>>
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org