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 19:56:04 UTC
RE: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.java FileItem.java FileUpload.java FileUploadException.javaMultipartStream.java
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.java FileItem.java FileUpload.java FileUploadException.javaMultipartStream.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri writes:
> Just to throw a spanner in, commiting code after reformatting it is
> a pain for cvs diffing. IntelliJ [which I use] code reformatting
> makes sense only if everyone is on the standard, or we have a
> standard. Else people bounce their own layouts back and forth and
> create cvs noise.
Steve Downey <st...@netfolio.com> writes:
> 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.
I am a very strong +1 on the above comments. I absolutely hate it
when functional and sytlistic changes are mixed; it makes it very
difficult to use CVS to later identify when a problem was introduced
into a code base.
The Golden Rule: When modifying code, format your modifications in its
existing style. Any modifications you make are more easily
maintainable, and are more digestable by the existing maintainers.
Your patch is more likely to be included, and causes less work for
those more closely associated with the project.
Any IDE or editor worth the bits its stored on (cough, XEmacs, cough
Emacs) can be easily configured to automatically indent code in any
style you can imagine.
"Code Complete" by Steve McConnell (an excellent books on programming
which should be required reading for any practicing programmer or
manager) provides excellent guidelines for this sort of thing.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.java
FileItem.java FileUpload.java FileUploadException.javaMultipartStream.java
Posted by Steve Downey <st...@netfolio.com>.
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: <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: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.java
FileItem.java FileUpload.java FileUploadException.javaMultipartStream.java
Posted by Henri Yandell <ba...@generationjava.com>.
Just to throw a spanner in, commiting code after reformatting it is a pain
for cvs diffing. IntelliJ [which I use] code reformatting makes sense only
if everyone is on the standard, or we have a standard. Else people bounce
their own layouts back and forth and create cvs noise.
On Mon, 19 Aug 2002, 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: <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>