commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: Coding conventions in Commons
Date Tue, 20 Aug 2002 04:36:40 GMT


> -----Original Message-----
> From: Morgan Delagrange [mailto:mdelagra@yahoo.com]
> Sent: Monday, August 19, 2002 8:27 PM
> To: Martin Cooper; 'Jakarta Commons Developers List';
> 'morgand@apache.org'
> Subject: RE: Coding conventions in Commons
> 
> 
> 
> --- Martin Cooper <martin.cooper@tumbleweed.com>
> wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: Morgan Delagrange
> > [mailto:mdelagra@yahoo.com]
> > > Sent: Monday, August 19, 2002 1:50 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: Coding conventions in Commons
> > > 
> > > 
> > > 
> > > --- "Geir Magnusson Jr." <geirm@adeptra.com>
> > wrote:
> > > > On 8/19/02 2:33 PM, "Martin Cooper"
> > > > <martin.cooper@tumbleweed.com> wrote:
> > > > 
> > > > >> From: Geir Magnusson Jr.
> > > > [mailto:geirm@adeptra.com]
> > > > >> 
> > [snip]
> > > > If I recall correctly, when we started commons,
> > the
> > > > intent was to let
> > > > components choose their own way...
> > > 
> > > Yes, we've definitely covered this ground several
> > > times in the past, including the discussions over
> > the
> > > charter.
> > > 
> > > Define the benefit of adopting coding conventions
> > that
> > > are not preferred by the programmers maintaining
> > the
> > > component.  Inconvenience for inconvenience's
> > sake?
> > 
> > Ah, well that's actually a different statement from
> > the ones that have been
> > made so far. What I've heard so far is people
> > wanting to retain the
> > conventions according to the original source of the
> > code. 
> 
> Yes, maintaining the style of inidivual classes is a
> different issue from defining and maintaining the
> style of the entire component.  I think you and I
> agree that, in practice, it's impractical to have
> multiple styles expressed in the same component.

Yes.

> 
> > But the people
> > currently maintaining the code in Commons may not
> > have been the same people
> > who did so in its original home, and they may have a
> > different preference
> > when it comes to coding conventions.
> 
> I think we would also agree that contributions to an
> existing component should be committed in the style of
> the component, not in the style of the contributor.

Yep.

> 
> > I don't think we'd want to go down that path. The
> > maintainers can change
> > over time, and I doubt we'd want to see the
> > conventions changing each time.
> > The conventions should be defined for the project,
> > and should stay that way
> > (unless there is a later agreement to change them
> > for some reason).
> 
> If you're saying that the entire Commons project
> should dictate the Sun Coding Convention for all
> components, here I disagree.  Per-component coding
> styles is the de-facto methodology in Commons and has
> not caused any difficulties to date (to my knowledge).
>  I think requiring a particular coding convention is
> contrary to sense and the spirit of sharing.  

Apparently, that is what I said, but it wasn't what I meant. Poor wording on
my part.

What I meant to say is that conventions should be defined for a body of
code, based on criteria that do not involve the individual contributors to
that body of code. That is, if I pick up a stalled Commons component (i.e.
one which is not being actively developed and/or maintained), then it is not
OK to reformat the code to my personal preferred style just because I want
to. However, the style of an originating code base for a body of code is a
suitable criterion for the retention of that style.

As for whether the granularity of a "body of code" is the Commons project or
each Commons component, I am ambivalent. I can understand arguments for
either approach.

All I ask is that, if we in Commons elect to allow different coding styles
per component, we clearly document that decision. That way, people won't
spend time converting an existing component to the Sun conventions because
they thought that was the requirement for Commons. (Which is exactly how all
this started.)

Finally, for new code being written specifically for a new Commons
component, that did not originate in some other code base, I think it would
be helpful to suggest a recommended coding style, and I see no reason not to
suggest the Sun conventions for that.

--
Martin Cooper


> 
> If a group of Turbine developers, for example, wish to
> break out a portion of their code into a reusable
> component in the Commons subproject, it's unreasonable
> to require reformatting that code if Turbine
> developers still form the majority of the new
> component's developers.  The Sun Coding Conventions
> are not the "official" conventions of Jakarta or
> Commons in any way, merely a suggestion.  Clearly the
> body of Turbine developers have their own opinions on
> how code should be formatted.  If over time, the
> makeup of a component's developers changes
> dramatically, they can always vote to reconsider the
> formatting, if the style is truly an impediment to
> development (which seems unlikely).
> 
> - Morgan
> 
> > --
> > Martin Cooper
> > 
> > 
> > > 
> > > > > That's why I started this thread in the first
> > > > place.
> > > > 
> > > > 
> > > >  
> > > > > --
> > > > > Martin Cooper
> > > > > 
> > > > > 
> > > > >> 
> > > > >> I personally detest many things about Sun's
> > > > conventions - I
> > > > >> can't see why
> > > > >> they invented a new style for a C/C++-like
> > > > language, so
> > > > >> coming from a C/C++
> > > > >> background (and Pascal, Fortran, etc...) it's
> > > > somewhat
> > > > >> grating sometimes,
> > > > >> but I am sure the same is true in reverse if
> > all
> > > > you have
> > > > >> known is Java...
> > > > >> (I also think there are good parts to it...) 
> > I
> > > > generally
> > > > >> believe that there
> > > > >> should be functional / working reasons for a
> > > > style, usually
> > > > >> specific to the
> > > > >> language it's for.
> > > > >> 
> > > > >> Anyway - I don't want to debate style.  Just
> > > > wanted to note I
> > > > >> think original
> > > > >> style should be respected, and each component
> > > > should be able
> > > > >> to choose it's
> > > > >> own style.
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >> -- 
> > > > >> Geir Magnusson Jr.
> > > > >> Research & Development, Adeptra Inc.
> > > > >> geirm@adeptra.com
> > > > >> +1-203-247-1713
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >> --
> > > > >> To unsubscribe, e-mail:
> > > > >>
> > > >
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > >> For additional commands, e-mail:
> > > > >> <mailto:commons-dev-help@jakarta.apache.org>
> > > > >> 
> > > > >> 
> > > > > 
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail:  
> > > >
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > 
> > > > 
> > > > -- 
> > > > Geir Magnusson Jr. 
> > > > Research & Development, Adeptra Inc.
> > > > geirm@adeptra.com
> > > > +1-203-247-1713
> > > > 
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:  
> > > >
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > 
> > > 
> > > 
> > > =====
> > > Morgan Delagrange
> > > http://jakarta.apache.org/taglibs
> > > http://jakarta.apache.org/commons
> > > http://axion.tigris.org
> > > http://jakarta.apache.org/watchdog
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > HotJobs - Search Thousands of New Jobs
> > > http://www.hotjobs.com
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > >
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: 
> > > <mailto:commons-dev-help@jakarta.apache.org>
> > > 
> > > 
> > 
> 
> 
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
> 
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message