commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Becksfort, Jared" <Jared.Becksf...@STJUDE.ORG>
Subject RE: [math] Formatting
Date Fri, 24 Aug 2012 01:29:18 GMT
> > [...]
>> 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).



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.


Email Disclaimer:
Consultation Disclaimer:

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

View raw message