Copying out of Jim's message into an appropriate titled message to
make
sure it doesn't get lost:
Dan also proposed we adopt checkstyle as part of the build process. I
would like to due this using lazy consensus with the caveat that the
cut-over be done after the Java One release to avoid disruption and
give people a chance to adjust code gradually. The checkstyle
configuration is fairly rigorous and we will need to divide up the
work to do so by project.
My information:
I've attached the "proposed" checkstyle.xml. In there, there are
links to checkstyles website that describes each of the checks. All
of the checkstyle checks are listed in the file, but many are
disabled.
They are left in the file so people can see what is available and we
can decide if we want them enabled or not.
There may need to be an additional change. The "beta" version of
the
next Checkstyle eclipse plugin uses a beta version of checkstyle 4.2.
It adds TYPECAST to the defaults for "NoWhitespaceAfter". Thus,
code
like:
Foo foo = (Foo) obj;
is marked illegal with the newer version. (the current maven
version
is OK) I notice we do that in many places (although there are
also a
lot of typecasts without the space). Anyway, if we want to
continue supporting both with and without spaces, that test would
need
to be updated to explicitly list the tokens we DO want. However, I
personally feel we should leave it as is and remove the spaces, but
that's my preference. Unfortunately, it would be hard to enforce
until checkstyle 4.2.
In general, the tests that require some discussion are:
1) AbstractClassName: what names should abstract classes have.
Celtix
has a couple. I haven't looked at tuscany much in this regard.
2) AvoidStarImport and ImportOrder - Celtix DOES allow star
imports for
some of the "java" packages (io, util, net, etc...) and junit. All
others cannot have start imports. We also order them more like the
old "C" ordering of "system stuff first" (java., javax. org.w3c.,
org.xml) followed by all other stuff, in alpha order.
3) Lengths always start good discussions. We limit LineLength to
110
(but the attached checkstyle is set to 115), Method Length to 150,
number of parameters to a method to 7, and AnonymousInnerClasses
set to
40 lines. (which seems high to me, but...)
I'd ALSO like this discussion done for the SDO and SPEC projects as
well as the generated code. But those can wait. Right now, those
parts are COMPLETELY different than the rest of the tuscany code.
It's a bit strange when debugging when you trace into that code as
suddenly everything looks different. I guess the question is: are
those parts part of the tuscany project or not. If not, should they
move to a different project? If so, shouldn't they follow the same
rules?
That all said, here's my +1. :-) Definitely wait until after
JavaOne. I'd definitely be willing to help out, possibly even willing
to commit to doing a module a day.
Enjoy!
