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 05:53:07 GMT


> -----Original Message-----
> From: John McNally [mailto:jmcnally@collab.net]
> Sent: Monday, August 19, 2002 10:39 PM
> To: Jakarta Commons Developers List
> Subject: RE: Coding conventions in Commons
> 
> 
> Since Turbine's coding conventions have been mentioned a couple times,
> here is the link:
> 
> http://jakarta.apache.org/turbine/common/code-standards.html

Thanks, that's helpful.

> I think the only thing in opposition to Sun's recommendations is the
> placement of {} signifying beginning and ending of blocks are to be
> placed on their own lines.

Yes, that's the main difference I noticed in the FileUpload code base.

> Other things like mandating 4 space indentation and unix linefeeds are
> very beneficial for readability of cvs diffs and the source code in
> general.  Sun's conventions leave these vague, but I think it 
> is a good
> idea to standardize within a subproject or commons component.

I agree with "spaces, not tabs" indentation. The line ends point puzzles me,
though. Unless files are checked in as binary, CVS will serve up the local
line end format, and convert it upon commit. So there should be no issue
with line ends, assuming people aren't checking in text files as binary.

--
Martin Cooper


> 
> john mcnally 
> 
> 
> On Mon, 2002-08-19 at 15:40, Martin Cooper 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. 
> 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 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).
> > 
> > --
> > 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>
> > > 
> > > 
> > 
> > 
> > --
> > 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>



--
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