Somewhat off-topic at this point:
Actually, Sun's style is pretty specific for most things that matter.
The problem is probably that Sun code doesn't always follow Sun's
style.
re: Brace reformatting for readability, I prefer reading code with
braces lined up, but since over 70% of the C code I've read and almost
as much of the Java code I've read use the Kernigan and Richie style
bracing I've gotten used to reading it and writing it over the years.
I'm not sure if that's the kind of reformatting to which you're
refering, but it's good to learn both ways in any case.
For the format impaired:
K&R style:
if( you can read this ){
you'll go far
}
Versus:
if( you can read this )
{
you'd also like pascal
}
And actually, Sun-style would be:
if (you can read this){
you'll like tomcat code
}
(except replace the 8 spaces with a tab, leave everything else spaces;
the part that jakarta leaves out... thankfully.)
I've found it enlightening to be able to read and write all of these
styles "fluently"... especially when contributing to jakarta
projects. :) Ironically, none of them are my "native tongue" but I'm
an odd-ball.
-Paul Speed
Andrew Hill wrote:
>
> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
