I'm working on my JavaOne presentaiton right now, but we should start a Wiki page to discuss coding style. I may find time tomorrow to work on that a bit. Nobody can expect anybody to conform to an unwritten law!
On 4/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > P.S. I've been slowly but surely trying to fix up any and all checkstyle > errors/warnings found over the past few weeks. (I think close to a couple > thousand have been cleared out now). Tweaks to this shared configuration > would also help keep me in line. > > On 4/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > Yeah, sorry. Think I'm the guilty party again on this one :) Initially I > > was very frustrated with this coding style while doing tacos work, but have > > now found that it has saved me a lot of pain when trying to change the > > render cycle. > > > > I've traditionally preferred protected members by default, unless I knew > > that there just wasn't any possible reason why someone should have access to > > it or that anyone messing with it would screw things up. > > > > I should probably go read up on that article that Geoff pointed out ( > > http://www.eclipse.org/eclipse/development/java-api-evolution.html) as my > > experience developing API's that affect thousands vs tens of developers is > > pretty much non existant. > > > > > > On 4/9/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > We probably need to discuss coding style issues. > > > > > > For instance, a lot of the new code I'm looking at is using protected > > > instance variables. I favor private instance variables in almost all > > > cases, even when I'm designing a class to be extended ... but then I > > > provide protected or public accessor methods to those private fields. > > > > > > What I haven't done in Tapestry or HiveMind, but am starting to do in > > > Tapestry5, is to use "final" much more liberally. But that's another > > > discussion. > > > > > > In addition, a note about HiveMind services and Log. > > > > > > If you have a writable property named "log" (i.e. setLog() is the > > > setter method name), and the type is org.apache.commons.logging.Log , > > > then HiveMind will autowire that property to a Log instance based on > > > the *service* name (not the implementation class name). This is > > > actually a function of the default service factory, > > > hivemind.BuilderFactory . > > > > > > This is good for testing, since its easier to provide a mock > > > implementation of Log than to deal with the Log created by the class > > > for itself (the traditional approach). > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > Independent J2EE / Open-Source Java Consultant > > > Creator, Jakarta Tapestry > > > Creator, Jakarta HiveMind > > > > > > Professional Tapestry training, mentoring, support > > > and project work. http://howardlewisship.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Jesse Kuhnert > > Tacos/Tapestry, team member/developer > > > > Open source based consulting work centered around > > dojo/tapestry/tacos/hivemind. http://opennotion.com > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://opennotion.com > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
