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:[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]>
