commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
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:


> Jared
> Email Disclaimer: Consultation
> Disclaimer:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message