Personally I find the sun style with things just anyhow all over the place to be quite messy & completely unreadable.
When I read source for a struts class I usually have to spend 10 minutes moving the braces around so I can figure out what is going on... Still one mans meat is anothers poison, and if theres one thing in development that is bound to spark off 'holy wars' its coding style ;-) -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 03:53 To: Struts Developers List Subject: Re: Avoid code reformating ! It's true that since the Struts product does not define its own code standards, we default to the Sun conventions, as given by the Jakarta guidelines. Personally, I augment these with the Java Elements of Style, which, in practice, act like a superset of the Sun conventions. As a practical matter, we do have to balance "Observe the style of the original" with our responsibility to maintain a code base for the benefit of others (rather than ourselves). Technically, we should veto submissions that do not follow the Sun coding conventions, but we've been lax about that in the past. I would simply suggest that we continue to follow the practice of submitting code changes and style changes separately. If someoone has a stylistic scratch to itch, they should scratch it. (But it would be polite to find a bug itch to scratch first =:) Incidentally, the tab thing is because we email the deltas and sending tabs by email is problematic =:( -Ted. 12/16/2002 6:44:07 PM, David Graham <[EMAIL PROTECTED]> wrote: >A couple of things: >1. Tabs were addressed as an issue but the jakarta guidelines state that >tabs are not to be used in the first place. This drives me crazy but I >follow it nonetheless. >2. I agree with closing one line blocks but this isn't in any standard. >I've seen a lot of Struts code that will follow an unclosed one line block >with more code which makes it very confusing. This is fair game for >changing in my book. >3. I disagree that we should stop formatting code. We have a standard that >we should be following. If we need to change that standard then we can >debate that. > >Dave > > > > > > >>From: Erik Hatcher <[EMAIL PROTECTED]> >>Reply-To: "Struts Developers List" <struts- [EMAIL PROTECTED]> >>To: Struts Developers List <[EMAIL PROTECTED]> >>Subject: Re: Avoid code reformating ! >>Date: Mon, 16 Dec 2002 18:25:55 -0500 >> >>As for seeing a class structure, this is what IDE's like Eclipse and IDEA >>make a moot point. I think if code doesn't follow the Jakarta (or >>project-specific) conventions then its fair game for reformatting. This is >>communal code and no one person owns it, this is why conventions exist and >>we must adhere to them for the sake of the "community". Please. >> >>But, while we are talking about coding conventions, at least please adopt >>closing if/for/while/etc blocks with curly brackets for one-line blocks. >>The Struts codebase is littered with non-curly-bracketed one- line blocks >>and that in and of itself drives me nuts when I'm trying to follow the >>code. :)) >> >> Erik >> >> >>Cedric Dumoulin wrote: >>> >>> I said that I don't want to debate on this. I know the reformated code >>>doesn't follow the recomanded Jakarta rules code standard. But another >>>rule is to respect any other well formated standard ;-). >>> For me, the reformated code is really unreadable: I can't detect the >>>classes and methods structures at a glance, and so it requires me some >>>times to try to figure it out. I thing it is a waste of time ... >>> >>> Cedric >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> > > >_________________________________________________________________ >Protect your PC - get McAfee.com VirusScan Online >http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [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]>
