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

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

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-01-26 22:59:33 CET

On Thu, 26 Jan 2006, Justin Erenkrantz wrote:

> On 1/26/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> > Cool! Do you care to explain why you think we should choose a style that
> > most of our existing ocde does *not* use? There might be good arguments,
> > but since I haven't seen them, I can't evaulate them.
>
> Perhaps the =) didn't come across, but I'm against forcing a decision
> on this particular point - namely that our policy in place is correct:

Yes, the smiley came through, but what that really meant in this context
was unclear to me.

> be internally consistent.
>
> There's a reason why we allow this choice: it's a bikeshed. We all
> have better things to do then listen to people debate the merits of
> parens spacing. -- justin
>
Yeah, even I have more important stuff to do, but I also have more
important stuff to do than continously paying attention to this silly
detail while editing different source files at the same time.

Others also have agreed that this is a real problem. Why is it so
important to be able to choose one's own style in this respect, when one
has to adapt in so many other ways? If it was only you who had to
maintain the code yo add, then I wouldn't care a tlot, but since I'm
active in the svn project, I will have to work on it as well. All I'm
asking for is consitency, not that people follow my preferred style.

Thanks,
//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 23:01:37 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.