[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

From: olafBuddenhagen
Subject: Re: [PATCH 1/3] Add a new exec_exec_file_name RPC
Date: Wed, 2 Jun 2010 00:00:13 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Tue, Jun 01, 2010 at 11:39:42AM +0200, Carl Fredrik Hammar wrote:
> On Tue, Jun 01, 2010 at 03:52:59AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote:

> > > Break these two lines.  Try to stick to less than 76 columns or
> > > less than 80 if the reformatting changes lines that would
> > > otherwise be unaffected.
> > 
> > Why 76?
> It seems I'm missremembering.  The number doesn't seem to be clearly
> stated in the GNU Coding Standards, but indent --gnu uses 78.

Keep in mind that this convention stems from a time where people
actually used to *print* code, on a 80 column line printer... So it was
important to strictly observe the limit back then. Nowadays, screens are
large enough that a) nobody feels the urge to print out code, and b)
nobody has a reason to stick to 80 columns when viewing on screen.

Of course, very long lines can be hard to read; so depending on the
content, breaking is still often advisable. However, there are many
cases where breaking too soon adds nothing to readability, and even
makes it worse. Pretty much all the cases you nagged about fall in this
category IMHO...

So unless there is a pedantic upstream who won't accept patches not
strictly conforming to a fixed column number, I'm *strongly* against
observing it too closely.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]