You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Scott Sanders <ss...@nextance.com> on 2002/08/19 20:50:01 UTC
RE: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.javaFileItem.javaFileUpload.javaFileUploadException.javaMultipartStream.java
I think that is a great idea. Call for a VOTE. I am willing to change
the standard. I am unwilling to not follow the current standard.
Scott
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, August 19, 2002 11:44 AM
> To: Jakarta Commons Developers List
> Subject: Re: cvs commit:
> jakarta-commons-sandbox/fileupload/src/java/org/apache/commons
> /fileuploadDefaultFileItem.javaFileItem.javaFileUpload.javaFil
> eUploadException.javaMultipartStream.java
>
>
>
> Scott Sanders wrote:
> > So you are not stopping me, just recommending that I do not?
> >
> > If so, then why do we publish standards?
>
> Better question: why do we publish useless standards and not more
> pragmatic ones, that for example put the accent on the javadocs and
> documentation insteat of style?
>
> >>-----Original Message-----
> >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>Sent: Monday, August 19, 2002 11:16 AM
> >>To: Jakarta Commons Developers List
> >>Subject: Re: cvs commit:
> >>jakarta-commons-sandbox/fileupload/src/java/org/apache/commons
> >>/fileuploadDefaultFileItem.javaFileItem.javaFileUpload.java
> >>FileUploadException.javaMultipartStream.java
> >>
> >>
> >>
> >>
> >>Scott Sanders wrote:
> >>
> >>>Agreed from the separation perspective, but the notion that I
> >>>shouldn't commit style changes to conform to a standard because of
> >>>stats is ludicrous.
> >>>
> >>>So, if I use IntelliJ to reformat to the currently accepted
> >>
> >>standard,
> >>
> >>>ie the jakarta standard since Commons has not created one of their
> >>>own, why should I not commit that?
> >>
> >>I never said that.
> >>I don't care if you do.
> >>
> >>But I wouldn't encourage you to do it, that's all.
> >>
> >>
> >>
> >>>>-----Original Message-----
> >>>>From: Steve Downey [mailto:steve.downey@netfolio.com]
> >>>>Sent: Monday, August 19, 2002 11:09 AM
> >>>>To: Jakarta Commons Developers List
> >>>>Subject: Re: cvs commit:
> >>>>jakarta-commons-sandbox/fileupload/src/java/org/apache/commons
> >>>>/fileuploadDefaultFileItem.javaFileItem.java FileUpload.java
> >>>>FileUploadException.javaMultipartStream.java
> >>>>
> >>>>
> >>>>Code reformat commits should be separate from any other commits.
> >>>>Otherwise, you end up sifting through a lot of
> meaningless diffs to
> >>>>find out what really changed.
> >>>>
> >>>>Scott Sanders wrote:
> >>>>
> >>>>
> >>>>
> >>>>>So, if I am using something as wonderful as Intellij, and I
> >>>>
> >>>>happen to
> >>>>
> >>>>
> >>>>>format the code to the current standard, I cannot/should not
> >>>>
> >>>>commit it?
> >>>>
> >>>>
> >>>>>I would tend to disagree with this. I think there does need
> >>>>
> >>>>to be some
> >>>>
> >>>>
> >>>>>common standard, although I do not care what it is. I am
> >>>>
> >>>>much faster
> >>>>
> >>>>
> >>>>>at understanding code if it looks the same as the code
> that I just
> >>>>>looked at.
> >>>>>
> >>>>>Scott
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>>>>>Sent: Monday, August 19, 2002 10:49 AM
> >>>>>>To: Jakarta Commons Developers List
> >>>>>>Subject: Re: cvs commit:
> >>>>>>jakarta-commons-sandbox/fileupload/src/java/org/apache/commons
> >>>>>>/fileuploadDefaultFileItem.java FileItem.java FileUpload.java
> >>>>>>FileUploadException.javaMultipartStream.java
> >>>>>>
> >>>>>>
> >>>>>>I find reformatting of code a useless task.
> >>>>>>Each of us has his own style, and has to learn to work with
> >>>>>
> >>>>different
> >>>>
> >>>>
> >>>>>>styles.
> >>>>>>If the code was so horrible that it's not
> understandable, I really
> >>>>>>think that no reformatting can make it better.
> >>>>>>
> >>>>>>If someone needs to reformat the code to understand it
> >>>>>
> >>better, then
> >>
> >>>>>>there are various automatic formatters available. If
> >>>>>
> >>someone likes
> >>
> >>>>>>to spend his time reformatting his code by hand, it's
> >>>>>>*his* problem, not mine.
> >>>>>>
> >>>>>>But please, leave alone the code that's already there, so
> >>>>>
> >>>>that we can
> >>>>
> >>>>
> >>>>>>have meaningful CVS diffs and automatic code diff metrics.
> >>>>>>
> >>>>>>
> >>>>>>Scott Sanders wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I would tend to agree with this. Commons does not use
> >>>>>>
> >>the Turbine
> >>
> >>>>>>>convention. I don't think code in Commons should be style
> >>>>>>>
> >>>>>>
> >>>>>>as to where
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>it came from.
> >>>>>>>
> >>>>>>>Scott
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: Lavandowska [mailto:flanandowska@yahoo.com]
> >>>>>>>>Sent: Sunday, August 18, 2002 1:22 PM
> >>>>>>>>To: Jakarta Commons Developers List
> >>>>>>>>Subject: Re: cvs commit:
> >>>>>>>>jakarta-commons-sandbox/fileupload/src/java/org/apache/commons
> >>>>>>>>/fileupload DefaultFileItem.java FileItem.java
> >>>>>>>>FileUpload.java FileUploadException.java MultipartStream.java
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Since it is no longer a part of Turbine, doesn't it make
> >>>>>>>
> >>>>more sense
> >>>>
> >>>>
> >>>>>>>>for it to change to the Sun conventions? That is the common
> >>>>>>>>denominator in commons, isn't it?
> >>>>>>>>
> >>>>>>>>--- Jason van Zyl <ja...@zenplex.com> wrote:
> >>>>>>>>
> >>>>>>>
> >>>>>>...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>It used the one's that Turbine has used forever.
> >>>>>>>>
> >>Would you mind
> >>
> >>>>>>>>>putting the code back to its original style? The Maven
> >>>>>>>>
> >>>>checkstyle
> >>>>
> >>>>
> >>>>>>>>>plugin supports the Turbine mode and I believe this is
> >>>>>>>>
> >>>>fair to ask
> >>>>
> >>>>
> >>>>>>>>>given that
> >>>>>>>>>the code originally came from the Turbine code base.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>--
> >>>>>>Nicola Ken Barozzi nicolaken@apache.org
> >>>>>> - verba volant, scripta manent -
> >>>>>> (discussions get forgotten, just code remains)
> >>>>>>------------------------------------------------------------
> >>>>>
> >>>>---------
> >>>>
> >>>>
> >>>>>>--
> >>>>>>To unsubscribe, e-mail:
> >>>>>><mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> >>>>>>For
> >>>>>>additional commands,
> >>>>>>e-mail: <ma...@jakarta.apache.org>
> >>>>>>
> >>>>>>
> >>>>>--
> >>>>>To unsubscribe, e-mail:
> >>>>
> >>>><mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> >>>>
> >>>>>For
> >>>>
> >>>>additional commands,
> >>>>e-mail:
> >>>>
> >>>>
> >>>>><ma...@jakarta.apache.org>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>--
> >>>>To unsubscribe, e-mail:
> >>>><mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> >>>>For
> >>>>additional commands,
> >>>>e-mail: <ma...@jakarta.apache.org>
> >>>>
> >>>>
> >>>--
> >>>To unsubscribe, e-mail:
> >>
> >><mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> >>
> >>>For
> >>
> >>additional commands,
> >>e-mail:
> >>
> >>><ma...@jakarta.apache.org>
> >>>
> >>>
> >>>
> >>
> >>--
> >>Nicola Ken Barozzi nicolaken@apache.org
> >> - verba volant, scripta manent -
> >> (discussions get forgotten, just code remains)
> >>------------------------------------------------------------
> ---------
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >><mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> >>For
> >>additional commands,
> >>e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Adopt Minimal Coding Standards
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Juozas Baliuka" <ba...@centras.lt> writes:
> I see javadoc stuff very usefull and I think we can't ignore this:
>
> http://jakarta.apache.org/site/library.html
> "The Java Code Conventions
> This Sun document specifies the de-facto standard way of formatting Java
> code. All code written for this project must follow these conventions."
>
> As I understand it is for *all* jakarta projects and it must not be problems
> with
>
> code "taken from other projects"
The definitive reference is:
http://jakarta.apache.org/site/source.html
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Adopt Minimal Coding Standards
Posted by Juozas Baliuka <ba...@centras.lt>.
I see javadoc stuff very usefull and I think we can't ignore this:
http://jakarta.apache.org/site/library.html
"The Java Code Conventions
This Sun document specifies the de-facto standard way of formatting Java
code. All code written for this project must follow these conventions."
As I understand it is for *all* jakarta projects and it must not be problems
with
code "taken from other projects"
----- Original Message -----
From: "Morgan Delagrange" <md...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<ni...@apache.org>
Sent: Monday, August 19, 2002 9:28 PM
Subject: Re: [VOTE] Adopt Minimal Coding Standards
>
> --- Nicola Ken Barozzi <ni...@apache.org> wrote:
>
> <snip/>
>
> > I propose that we change the Commons coding
> > convention standards so that
> > they are more pragnatic and geared towards
> > respecting the projects from
> > which they originated.
>
> It's a little early for a vote, I think. Let's hash
> out the proposal first.
>
> > This doesn't mean that massive code reformattig
> > should never be done,
> > but that it's not recomended, and that it should be
> > decided beforehand.
> >
> > The new standards would be according to the
> > resolution adopted by the
> > POI project:
> >
> http://jakarta.apache.org/poi/resolutions/res001.html
> >
> > "
> >
> > 1. All classes and interfaces MUST have, right
> > at the beginning, the
> > ApacheCommons License .
> >
> > 2. All classes and interfaces MUST include class
> > javadoc.
> > Conventionally, this goes after the package and
> > imports, and before the
> > start of the class or interface. The class javadoc
> > MUST have at least
> > one @author tag.
> >
> > 3. All methods that are accessible outside the
> > class MUST have
> > javadoc comments. In other words, if it isn't
> > private, it MUST have
> > javadoc comments. Simple getters can consist of a
> > simple @return tag;
> > simple setters can consist of a simple @param tag.
> > Anything else
> > requires some verbiage plus all the standard javadoc
> > tags as
> > appropriate. You MUST include @throws or @exception
> > for any non-runtime
> > exceptions, and you SHOULD document any runtime
> > exceptions you expect to
> > throw. @throws/@exception tags SHOULD include an
> > explanation of why that
> > exception would be thrown. If your method might
> > return null, you MUST
> > say so. An accompanying explanation of the
> > circumstances for doing so
> > would be nice.
> > "
>
> That sounds good to me.
>
> > They would also contain the following:
> >
> > "
> > Every change to the code should not alter
> > substantially the coding
> > conventions adopted by the original author.
> > It is reccomended that classes created within
> > Commons and not taken from
> > other projects follow the Sun Coding Convention
> > guidelines.
> > "
>
> How about something more like:
>
> Each Commons component should use an internally
> consistent and documented coding style. If a
> component does not specify its coding style,
> the Sun Coding Convention guidelines are
> assumed.
>
> >
> > --
> > Nicola Ken Barozzi
> > nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> >
> ---------------------------------------------------------------------
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Adopt Minimal Coding Standards
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Nicola Ken Barozzi <ni...@apache.org> wrote:
<snip/>
> I propose that we change the Commons coding
> convention standards so that
> they are more pragnatic and geared towards
> respecting the projects from
> which they originated.
It's a little early for a vote, I think. Let's hash
out the proposal first.
> This doesn't mean that massive code reformattig
> should never be done,
> but that it's not recomended, and that it should be
> decided beforehand.
>
> The new standards would be according to the
> resolution adopted by the
> POI project:
>
http://jakarta.apache.org/poi/resolutions/res001.html
>
> "
>
> 1. All classes and interfaces MUST have, right
> at the beginning, the
> ApacheCommons License .
>
> 2. All classes and interfaces MUST include class
> javadoc.
> Conventionally, this goes after the package and
> imports, and before the
> start of the class or interface. The class javadoc
> MUST have at least
> one @author tag.
>
> 3. All methods that are accessible outside the
> class MUST have
> javadoc comments. In other words, if it isn't
> private, it MUST have
> javadoc comments. Simple getters can consist of a
> simple @return tag;
> simple setters can consist of a simple @param tag.
> Anything else
> requires some verbiage plus all the standard javadoc
> tags as
> appropriate. You MUST include @throws or @exception
> for any non-runtime
> exceptions, and you SHOULD document any runtime
> exceptions you expect to
> throw. @throws/@exception tags SHOULD include an
> explanation of why that
> exception would be thrown. If your method might
> return null, you MUST
> say so. An accompanying explanation of the
> circumstances for doing so
> would be nice.
> "
That sounds good to me.
> They would also contain the following:
>
> "
> Every change to the code should not alter
> substantially the coding
> conventions adopted by the original author.
> It is reccomended that classes created within
> Commons and not taken from
> other projects follow the Sun Coding Convention
> guidelines.
> "
How about something more like:
Each Commons component should use an internally
consistent and documented coding style. If a
component does not specify its coding style,
the Sun Coding Convention guidelines are
assumed.
>
> --
> Nicola Ken Barozzi
> nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>
---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Adopt Minimal Coding Standards
Posted by Nicola Ken Barozzi <ni...@apache.org>.
>>Scott Sanders wrote:
>>
>>> If so, then why do we publish standards?
>>
>> Better question: why do we publish useless standards and not more
>> pragmatic ones, that for example put the accent on the javadocs and
>> documentation insteat of style?
...
>> I find reformatting of code a useless task.
>>
>> Each of us has his own style, and has to learn to work with
>> different styles.
>> If the code was so horrible that it's not understandable, I
>> really think that no reformatting can make it better.
>>
>> If someone needs to reformat the code to understand it
>> better, then there are various automatic formatters available. If
>> someone likes to spend his time reformatting his code by hand, it's
>> *his* problem, not mine.
>>
>> But please, leave alone the code that's already there, so
>> that we can have meaningful CVS diffs and automatic code diff metrics.
I propose that we change the Commons coding convention standards so that
they are more pragnatic and geared towards respecting the projects from
which they originated.
This doesn't mean that massive code reformattig should never be done,
but that it's not recomended, and that it should be decided beforehand.
The new standards would be according to the resolution adopted by the
POI project: http://jakarta.apache.org/poi/resolutions/res001.html
"
1. All classes and interfaces MUST have, right at the beginning, the
ApacheCommons License .
2. All classes and interfaces MUST include class javadoc.
Conventionally, this goes after the package and imports, and before the
start of the class or interface. The class javadoc MUST have at least
one @author tag.
3. All methods that are accessible outside the class MUST have
javadoc comments. In other words, if it isn't private, it MUST have
javadoc comments. Simple getters can consist of a simple @return tag;
simple setters can consist of a simple @param tag. Anything else
requires some verbiage plus all the standard javadoc tags as
appropriate. You MUST include @throws or @exception for any non-runtime
exceptions, and you SHOULD document any runtime exceptions you expect to
throw. @throws/@exception tags SHOULD include an explanation of why that
exception would be thrown. If your method might return null, you MUST
say so. An accompanying explanation of the circumstances for doing so
would be nice.
"
They would also contain the following:
"
Every change to the code should not alter substantially the coding
conventions adopted by the original author.
It is reccomended that classes created within Commons and not taken from
other projects follow the Sun Coding Convention guidelines.
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>