commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: cvs commit: jakarta-commons-sandbox/fileupload/src/java/org/apache/commons/fileuploadDefaultFileItem.java FileItem.java FileUpload.java FileUploadException.javaMultipartStream.java
Date Wed, 21 Aug 2002 02:13:40 GMT
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 <steve.downey@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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message