[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: |
Carl Fredrik Hammar |
Subject: |
Re: [PATCH 1/3] Add a new exec_exec_file_name RPC |
Date: |
Wed, 2 Jun 2010 13:28:21 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
Hi,
On Wed, Jun 02, 2010 at 12:00:13AM +0200, olafBuddenhagen@web.de wrote:
> 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.
Actually, two 80 column terminals fit nicely side by side on a 1280
pixel wide screen with a reasonable font size. ;-)
> 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...
I don't feel my suggestion would hamper readability. While they do break
up some nicely grouped arguments, the "orphaned" argument is a variable
with a name which clarifies its purpose in most if not all cases.
> 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.
I don't believe I observed it too closely in except a few cases, but
I'll try to be more lax next time.
Regards,
Fredrik