Any .java file can be javadoced. Only takes a little time to watch it churn through the source. It won't necessarily be useful if the comments are done right, but then again, bad comments won't make the source much more useful either. :) It will at least show you methods and hierarchy, etc.
For what it's worth, when I first started Java programming I put the private/protected member variables at the bottom. I gave up the practice when all of the other source code I read did it a different way... and when I had trouble resolving which should come first: inner classes or private/protected members. Talk about encapsulation, when you have to grep the file to find your member variables, that's a little too hidden. :) -Paul James Higginbotham wrote: > > Very true - if the project javadocs their code.. > > <quote>Since many OSS projects (not struts) only offer source as their > doco...</quote> > > My argument was for projects that don't, and thus the source is the > doco. If the project takes the time, then you are right.. > > James > > > -----Original Message----- > > From: Paul Speed [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 07, 2003 1:11 PM > > To: Struts Developers List > > Subject: Re: Struts Coding Standard > > > > > > Javadocs make this argument less relevant. If you are > > looking at the source then you need to see the guts. > > Otherwise, use the javadocs. > > > > I'm also not a committer, just my $0.02, > > -Paul > > > > James Higginbotham wrote: > > > > > > I'm not a contributer, but just to mention about putting > > field at the > > > end of a class definition, I agree.. It tends to jive > > better with the > > > concept of encapsulation.. Anyone reading the source can see what > > > constructors and public methods (sorted to the top) are available > > > first. They shouldn't have to worry about fields unless they are > > > getting into the guts. Since many OSS projects (not struts) > > only offer > > > source as their doco, it allows visitors to quickly get up to speed > > > with the API without worrying about the internals. Just my > > thoughts on > > > this.. > > > > > > James > > > > > > > -----Original Message----- > > > > From: David Graham [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, January 07, 2003 10:39 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Struts Coding Standard > > > > > > > > > > > > > > > > > >Another practice I reciently started is placing fields at > > > > the very end > > > > >of a > > > > >class definition, after all methods. It makes comparing > > the class > > > > >and it's interface. But since struts doesn't use many > > > > interfaces this isn't > > > > >a must > > > > >for me. > > > > > > > > > >-Rob > > > > > > > > That's certainly not a common practice and would confuse > > most Java > > > > developers looking for the member variables. > > > > > > > > Dave > > > > > > > > _________________________________________________________________ > > > > Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* > > > > http://join.msn.com/?page=features/junkmail > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:struts-dev-> [EMAIL PROTECTED]> > > > > For > > > > additional commands, > > > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:struts-dev-> [EMAIL PROTECTED]> > > > For > > additional commands, > > e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > > <mailto:struts-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
