[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[STYLE] Re: svn commit: r18218 - in trunk: . subversion/libsvn_ra_serf

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-01-26 10:13:01 CET

On Wed, 25 Jan 2006, Daniel Rall wrote:

> On Wed, 25 Jan 2006, Greg Stein wrote:
>
> > On Wed, Jan 25, 2006 at 10:44:45PM +0100, Peter N. Lundblad wrote:
> > >...
> > > I won't go on pushing this issue, because we can spend our lifes on more
> > > useful stuff than style discussions and I guess this debate has been up
> > > before. I just want to point out that anyones personal preference is
> > > rather irrelevant here. My motivation is maintainability.
> >
> > Personal preference *is* relevant. That was defined long ago. An
> > author (not-really when starting a new file, but definitely for a
> > whole library) can choose to use space-before-paren on function calls,
> > or no-space. And it should be consistent. But the choice has been
> > there since the SVN project started nearly six years ago.
>
> Clearly; we're still suffering from it today. I hate the
> space-before-paren style, but more of the code is written in that
> style, and like Lundblad, I'd rather keep things consistent for easier
> maintenance and a lower barrier-to-entry.
>
I don't understand why we on earth want such a "choice". I hereby propose
that we change our policy to say that new code should follow the
space-before-parent rule (if it is not part of existing files or modules
where the other rule appies). This "choice" hurts maintainability; lets'
not make it worse.

(I said I won't put this further, but now that I think of it I just want
this to be decided once and forever.)

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 26 10:13:33 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.