public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miles Bader <miles@gnu.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Whitcroft <apw@canonical.com>,
	Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ptrace: checkpatch fixes
Date: Thu, 09 Apr 2009 17:46:35 +0900	[thread overview]
Message-ID: <buo1vs2i590.fsf@dhlpc061.dev.necel.com> (raw)
In-Reply-To: <20090409030440.GA9169@elte.hu> (Ingo Molnar's message of "Thu, 9 Apr 2009 05:04:40 +0200")

Ingo Molnar <mingo@elte.hu> writes:
> We could also up the limit to 90 or 100 columns. My terminals are at 
> 90 columns and that's still pretty ergonomic. 100 is too wide to me 
> personally. (i'd argue that lines longer than 100 fall outside the 
> brain's 'field of view' cache and are beyond a general complexity 
> threshold as well, so they are not efficient to read, regardless of 
> monitor size and quality.)

I agree that _really_ wide lines start to make the code unreadable.

I find 80-column terminals/editor-windows still quite useful because
you can fit two of them side-by-side on almost every display, and I
think it's more useful to have multiple display contexts active than
it is to have huge amounts of whitespace at the ends of all my lines
(after all, comments aside, most code doesn't seem to be all _that_
wide -- the issue here is what happens with the minority that is).

Maybe given a blank slate, 90 columns or so might fit current coding
practices slightly better, but 80-columns seems to still be the
default in many cases (if you just say "xterm" you'll get an 80-column
terminal), and is in practice a very reliable _minimum_, so if you
want to avoid annoying people with hard-wrapping, 80 columns seems
like a pretty reasonable standard width...

-Miles

-- 
Politics, n. A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.

  reply	other threads:[~2009-04-09  8:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08  6:21 [PATCH] ptrace: checkpatch fixes Roland McGrath
2009-04-08  7:26 ` Sergio Luis
2009-04-08 12:50   ` Roland McGrath
2009-04-08 20:49     ` Sergio Luis
2009-04-08 17:19 ` Linus Torvalds
2009-04-08 19:57   ` Christian Borntraeger
2009-04-08 20:44     ` Linus Torvalds
2009-04-09  3:04   ` Ingo Molnar
2009-04-09  8:46     ` Miles Bader [this message]
2009-04-09 15:00     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=buo1vs2i590.fsf@dhlpc061.dev.necel.com \
    --to=miles@gnu.org \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox