Heh.. This is why I cringed at the thought of revamping standards for Struts - so many people have seen and like so many things. ;)
Craig - pick a few trusted folks, change them and make people stick with them, or leave them alone. Please don't let this get too out of hand.. I know, everyone is trying to help and I appreciate that, believe me. My guess is that those outside of commiters have to post a patch with the code anyway, so a commiter will just retrofit it to the standard anyway. Again, I'm on the outside looking in and mean no ill harm to anyone.. Just hate to see too many cycles burned on this by all involved.. James > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 07, 2003 1:49 PM > To: Struts Developers List > Subject: RE: Struts Coding Standard > > > > > On Tue, 7 Jan 2003, David Graham wrote: > > > Like you said, Struts does not use the source as the > documentation. > > The majority of people looking at the source are contributors and > > people looking to extend the framework. Member variables > should be at > > the top if for no other reason than that's where people > expect them to > > be. > > You seem rather adamant that this is not common practise, and > that people would expect to find member variables at the top. > I find this perspective interesting, since I had never > encountered this until I started working with the Struts code > base, and would have been just as adamant about the opposite > point of view. My company's coding standards put variables at > the bottom, too. > > I have a mild preference for putting them at the top, for > similar reasons to Rob. It also means that you start out > looking at code at the top of the file, instead of a bunch of > member variables that you don't usually find interesting > until you've looked at the code that uses them. > > But I don't care all that much, and since the Struts code > base already has them at the top, it's simpler to just leave > them where they are than to munge the entire code base to > move them to the bottom. ;-) > > -- > Martin Cooper > > > > > > David > > > > > > > > > > > > > > >From: "James Higginbotham" <[EMAIL PROTECTED]> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> > > >To: "Struts Developers List" <[EMAIL PROTECTED]> > > >Subject: RE: Struts Coding Standard > > >Date: Tue, 7 Jan 2003 12:20:30 -0600 > > > > > >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]> > > > > > > _________________________________________________________________ > > MSN 8 with e-mail virus protection service: 2 months FREE* > > http://join.msn.com/?page=features/virus > > > > > > -- > > 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]>
