Checkstyle Thoughts

[iv...@comcast.net]

I am very curious about these Checkstyle issues.

I have advocated to all J2EE developers the need to use checkstyle on a daily basis.  We use Maven for our nightly build and continuous integration so it is easy.  I want the developers to learn what Checkstyle requires and apply it as they develop code.  I believe fixing all these Checkstyle errors after the fact so to speak is counter productive and takes longer than writing good code, including good javadocs in the first place.

I also insist that code should be peer reviewed, we have a checklist of things to consider, and thoroughly unit tested.  Unit tests help write the code in the first place and are indispensable when it comes time to refactor.

Am I being too strict here?  Isn't this the way these tools are supposed to be utilized.

I would appreciate any helpful comments on this either way.

--
Ivan S Kirkpatrick, PE
home 850 656 9107
cell 253 229 6605

Sooner or later, you're bound to go...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Checkstyle Thoughts

["Frank W. Zammetti" <fz...@omnytex.com>]

I personally agree with this, and in fact I take it a step further... my 
code at work has to have Checkstyle, PMD, JLint and FindBugs run against 
it regularly (I'm trying to actually put together a proposal for a build 
farm that would include daily reports eMailed directly to pertinent 
developers and their project leaders).  I am a very strong supporter of 
static code analysis and believe the code you get when using them winds 
up being better and more solid, so no, I would not say you are being too 
strict.

Java Web Parts as another example... currently I only have Checkstyle 
running against it, just haven't set up the other tasks yet.  But before 
I cut a release, I try and eliminate any complaints it has.  At the 
moment, the only things it reports are things I know are ignorable, and 
I just haven't figured out how to get it to ignore them just yet :)

All that being said, it can't apply the same way to existing code like 
Struts, that would be a bit unfair, and I would definitely argue that 
fixing these things after the fact is a very worth-wild exercise.  I 
wouldn't have gone off and started doing it if I didn't feel that way :) 
  Even if all that gets fixed is Javadoc comments, that makes Struts 
better IMO because better documentation is *always* a good thing, so 
it's worth it.  I don't see it as counter-productive at all.  I would 
agree that writing code that doesn't have any Checkstyle complaints from 
the start is better, but you can't fault anyone for them when a lot of 
the code was written before tools like Checkstyle were mainstream.  I 
certainly don't :)

Frank

ivank2005@comcast.net wrote:
> I am very curious about these Checkstyle issues.
> 
> I have advocated to all J2EE developers the need to use checkstyle on a daily basis.  We use Maven for our nightly build and continuous integration so it is easy.  I want the developers to learn what Checkstyle requires and apply it as they develop code.  I believe fixing all these Checkstyle errors after the fact so to speak is counter productive and takes longer than writing good code, including good javadocs in the first place.
> 
> I also insist that code should be peer reviewed, we have a checklist of things to consider, and thoroughly unit tested.  Unit tests help write the code in the first place and are indispensable when it comes time to refactor.
> 
> Am I being too strict here?  Isn't this the way these tools are supposed to be utilized.
> 
> I would appreciate any helpful comments on this either way.
> 
> --
> Ivan S Kirkpatrick, PE
> home 850 656 9107
> cell 253 229 6605
> 
> Sooner or later, you're bound to go...
> 
> ---------------------------------------------------------------------
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org