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!
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
checkstyle.xml
Description: application/crossover-xml
