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

Re: [PROPOSAL] Change of convention for multiline string literals

From: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2007-03-18 20:38:59 CET

At 09:46 PM 3/18/2007 +0300, Ivan Zhakov wrote:
>On 3/18/07, Jonathan Gilbert wrote:
>> Any chance of getting this patch applied? I'd much prefer to be working
>> with a sane inline file string literal format for the new authz test cases.
>
>Hi Jonathan,
>I'm ready to apply this patch, but I want some arguments to align
>SVN_NL to length of longest line. I prefer do not do this, because
>it's easier to lost them out of screen in this case. I'll apply your
>patch as is, if you give me some arguments for your approach.

Here is my thinking:

1. Screen space today is cheap -- sufficiently so that I don't have a lot
of sympathy for people who insist on hacking in 80x25 text-mode and then
complain that code takes up too much space. :-)

2. With SVN_NL immediately at the end of each line instead of lined up in a
column, it isn't easy to spot a line that is missing its SVN_NL. Lined up
in a column, it is glaringly obvious when a line doesn't end in a newline.

3. Having them lined up looks aesthetically neater, which reduces the
stress of anyone looking at and working with the code. Coding is an art
form; we may as well make our artwork pleasing, especially since the whole
world gets to look at it.

It wouldn't be the end of the world to not have the lined up, but it
somehow seems like a step backward from the direction the patch is taking
the code... :-)

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 18 20:41:40 2007

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.