That's why I love programming.. Its like building something out of Legos - you may build the same product as another person, but they will both be built differently. And, why I hate to get into coding standards debates. I'll shutup now (is that applause in the background?) ;)
> -----Original Message----- > From: Paul Speed [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 10:08 AM > To: Struts Developers List > Subject: Re: Struts Coding Standard > > > 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: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]>
