On 3/27/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 3/27/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On 3/27/06, Sandy McArthur <[EMAIL PROTECTED]> 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 ;-) Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
