commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [all] Line width and such minutiae
Date Tue, 28 Mar 2006 13:08:05 GMT
On 3/27/06, Rahul Akolkar <> wrote:
> On 3/27/06, Rahul Akolkar <> wrote:
> > On 3/27/06, Sandy McArthur <> wrote:
> <snip/>
> > > > P.S.- [pool] code is quite hard to read with all that horizontal
> > > > scrolling. Irrespective of the code already in place, maybe we should
> > > > stick to a reasonable (80?) character line width for new code?
> > >
> > > The code I contribute to apache is code I wrote for pleasure. The code
> > > I contribute is in the form that was most pleasurable for me to write
> > > in.

When contributing to a community code base, you also need to think
about how approachable your code is to other contributors, many / most
of whom may not currently be working on the project.

>>>I impose no restrictions on how others choose to write their code.
> > > If you wish to compensate me to write code differently or reject my
> > > contributions because of such trivial issues, that is fine. The ASL
> > > grants anyone the right reformat ASL licensed code however they see
> > > fit. I only request that I am not stripped of attribution for my
> > > contributions.
> <snap/>
> The comment wasn't about imposing restrictions, that would never work
> anyway. Even while writing for pleasure, a lot of components still
> check for style (I think its valuable). The line width style criteria
> has some valid reasons, not the least of which is its accessibility
> implication that those more fortunate tend to not realize. So, I am
> implicitly -0 for any *new* commits that are needlessly and
> consistently too wide which indicates my personal preference (a -1
> ofcourse would be an attempt to impose a restriction). And I will
> always respect your opinion, even if it doesn't match mine.
> Compensation never comes to my mind in face of any discussions on
> these mailing lists, that bit was a no-brainer.

+1 - regarding style issues, we have been fairly consistent in the following:

* When contributing code to an existing component, follow the style of
the surrounding code
* Decisions to change the coding style or set checkstyle / pmd / other
rules for style checking are made by (lazy) consensus at the component
level, with opinions of those actively working on the code having
greatest weight
* Separate reformatting commits from commits that change behavior and
try to avoid "extraneous diffs" in commits.

My personal preference is 80 column line widths, partly because this
makes diffs readable.

> As a sidebar, since attribution got mentioned -- its an old, widely
> discussed topic at the ASF. Some of us believe that author tags in
> source code are a distraction (doesn't mean we want everyone to change
> their opinion). It has to do with issues arising out of how you define
> the least unit of work that warrants an author tag, the tedium of
> having to remember to add an author tag while applying a patch, and
> issues of fairness (should the author tags be ordered by size of
> contribution to the source file, name, chronology). A lot of older
> projects traditionally had author tags, so its more effort to
> discontinue, but for newer projects, I personally have begun to prefer
> the no author tags policy. Accordingly, I will likely -1 a patch to
> the [scxml] code if the author insists on having an author tag. And
> maybe that means [scxml] will miss out on some valuable contributions
> from talented folks purely for that reason, but that is perhaps "the
> lesser of the two evils". Attribution then, gets handled via commit
> messages and the team page. All commit messages contain attribution as
> the case may be, and anyone who contributes any code -- be it a line
> or a million -- gets listed on the team page.

+1 and search the archives for lots of discussion about why we should
not be adding new @author tags.

> I find listening to the variety of opinions on almost all things here
> at the ASF makes me richer.

And thats the kind of "compensation" that keeps us all coming back ;-)


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

View raw message