One more comment: One complaint I've heard from developers about enabling checkstyle is:
It will (a) slow me down because (b) it doesn't match my style. a) Based on my experience on several projects where checkstyle was added, it's really not true in the long term. For the first week or so, it DOES slow people down a bit, but once developers started getting used to the style, got their IDE's setup, etc... it no longer is a problem. If you ask any of the Celtix developers, most of them don't even realize checkstyle is even there anymore. They've gotten used to the style so it's rare that they even hit it. Long term, and with larger teams (Celtix has about 14 active commiters and growing), it actually speeds up the development as debugging and tracing and reading other peoples code becomes much easier as it's all 100% consistent from a style standpoint. (there are still inconsistencies in algorithms and approaches and such, obviously, but I haven't found a tool for that yet. :-) b) That's the point. Consistency across an entire project is important as it speeds up the developers. See point (a). Your not conforming Anyway, I kind of relate enabling checkstyle to be similar to switching to a kinesis contoured keyboard or other ergo keyboard. (http://www.kinesis-ergo.com/contoured_usb.htm , highly recommended BTW) For the first week, you WILL be slower, but long term, there are a lot of good things that come out of it. Enjoy! Dan On Wednesday 26 April 2006 08:05, Daniel Kulp wrote: > 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]
