mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: - add-pselect-ppoll-system-call-implementation-tidy.patch removed from -mm tree
Date: Thu, 19 Jan 2006 17:24:47 +1100	[thread overview]
Message-ID: <1137651887.30084.118.camel@localhost.localdomain> (raw)
In-Reply-To: <20060119171708.7f856b42.sfr@canb.auug.org.au>

On Thu, 2006-01-19 at 17:17 +1100, Stephen Rothwell wrote:
> The limit on the length of lines is 80 columns and this is a hard limit.
> 
> Statements longer than 80 columns will be broken into sensible chunks.
> Descendants are always substantially shorter than the parent and are placed
> substantially to the right. The same applies to function headers with a long
> argument list. Long strings are as well broken into shorter strings.

We can submit patches for the cases where the guidelines listed in
Documentation/CodingStyle diverge from common sense. 

In _some_ cases, the text which one might put after the 80th column is
actually important to the flow of the program and really should be put
back into the 'normal' text area. That's fair enough -- I'm not arguing
that we should leave 80-column text areas behind altogether.

But in this case it's just the length argument to a memcpy, and there's
no real information there. Similarly, people have recently been observed
to start wrapping the strings in debugging printks onto a second line
gratuitously. In _those_ cases, it really is counter-productive -- it's
_fine_ if that text is off the right-hand side of the screen.

If your editor wraps it onto the next line, then that sucks -- but at
least it only sucks for _you_, and you wouldn't really benefit by the
proposed 'fix' anyway, because the proposed 'fix' is just to wrap it so
that it sucks for _all_ of us.

-- 
dwmw2


  reply	other threads:[~2006-01-19  6:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200601190052.k0J0qmKC009977@shell0.pdx.osdl.net>
2006-01-19  5:21 ` David Woodhouse
2006-01-19  6:17   ` Stephen Rothwell
2006-01-19  6:24     ` David Woodhouse [this message]
2006-01-19  6:30     ` Andrew Morton
2006-01-19  6:40       ` David Woodhouse
2006-01-19  6:36     ` David S. Miller
2006-01-19  6:47       ` Trond Myklebust
2006-01-19  7:02         ` Andrew Morton
2006-01-19  7:18           ` David Woodhouse
2006-01-19  8:09           ` David S. Miller
2006-01-19 15:51       ` James Morris
2006-01-20  2:17       ` Stephen Rothwell
2006-01-19  9:58     ` Alan Cox
2006-01-19 15:59       ` Jens Axboe
2006-01-20  8:33         ` David Woodhouse
2006-01-20  8:44           ` Andrew Morton
2006-01-20  8:59             ` David Woodhouse
2006-01-20 10:01               ` Eric Dumazet
2006-01-23  5:25                 ` David Woodhouse
2006-01-20 23:44               ` Adrian Bunk

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=1137651887.30084.118.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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

all inboxes | Powered by JetHome®