commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Formatting
Date Fri, 24 Aug 2012 07:33:56 GMT
Le 24/08/2012 03:29, Becksfort, Jared a écrit :
>>> [...]
>>> 
>>> Think about it from the standpoint of a new contributor.  How
>>> long does it take to prepare and get a patch committed for a) the
>>> new contributor and b) the committer who ends up applying the
>>> patch. More rules means more time.  It is that simple.  Either
>>> the new contributor has to keep fixing his or her patch so it
>>> complies with all of the rules or the committer applying it does
>>> that.  In either case, friction is introduced.  Fewer rules means
>>> less friction, which IMO is more important than cosmetics.
> 
>> There is friction if everyone wants to stick with his own style. 
>> And there is friction when one has to read poorly written code,
>> just the same as if you'd have to read a document with one word in
>> black, then one in red, followed by one in italic, then one in
>> bold, one in a 12-points font, one in 14-points font, one in times
>> and one in roman, etc.
> 
>> There is reason for formatting rules: make a pleasant read. People
>> have to make a little effort e.g. to type LaTeX code so that the
>> _reader_ can be more confortable. [And the effort is much less when
>> writing Javadoc.]
> 
>> The actual style is not so important as having a _single one_ (per
>> project, per programming language).
> 
>> Gilles
> 
> Hello,
> 
> I recently contributed my first patch last month and have a couple
> more to go, so I figure I can add something to the discussion of
> formatting being a barrier to entry.  I was initially a bit surprised
> at how much I code I needed to reformat, but I expected there to be
> some.  In retrospect, the initial patch I turned in was a bit sloppy.
> Importantly, though, Gilles paid attention enough to the issue I was
> patching and provided me with some pretty good feedback that
> eventually resulted in committed code.  Now as I prepare a couple of
> new patches, I don't think the style is a significant deterrent.  It
> definitely would be a deterrent though if patches were just rejected
> outright with little feedback.  I realize that requires a bit of a
> commitment on the part of the main developers, so I guess you will
> have to decide how much of a hassle it is.  If there are tons of new
> contributors, it might be too much effort, but I imagine that a lot
> of the code comes from repeat contributors and the main developers.
> 
> I realize not everyone uses Eclipse, but you can pretty easily set up
> code formatting for individual projects.  It also allows for code
> styles to be exported and imported.  Maybe it would be helpful to
> make a code style available for download.

There is one here for eclipse:
  <http://people.apache.org/~luc/Apache-commons.xml>.

Luc

> 
> Jared
> 
> Email Disclaimer:  www.stjude.org/emaildisclaimer Consultation
> Disclaimer:  www.stjude.org/consultationdisclaimer
> 
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


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


Mime
View raw message