All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stuart MacDonald" <stuartm@connecttech.com>
To: 'Satyam Sharma' <satyam.sharma@gmail.com>,
	'Andrew Morton' <akpm@linux-foundation.org>
Cc: 'Christoph Hellwig' <hch@infradead.org>,
	'Roland McGrath' <roland@redhat.com>,
	'Christoph Hellwig' <hch@lst.de>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: RE: condingstyle, was Re: utrace comments
Date: Tue, 1 May 2007 12:15:00 -0400	[thread overview]
Message-ID: <001601c78c0b$deb12a30$294b82ce@stuartm> (raw)
In-Reply-To: <a781481a0704301142sfec317cu8213750c9ab84416@mail.gmail.com>

From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
               ^^^^^^^^^^^^^^^^^^^^^^^
> 
> 	if (veryverylengthycondition1 &&
> 		smallcond2 &&
> 		(conditionnumber3a ||
> 		condition3b)) {
> 		...
> 	}
> 
> versus

Whoops! You've got an unterminated if there, let me fix it up...

> 	if (veryverylengthycondition1) {
> 	    && smallcond2
> 	    && (conditionnumber3a
> 	        || condition3b)) {
> 		...
> 	}> 

From: On Behalf Of Scott Preece
> I still find the leading-operator style much more readable. The most
> important thing in reading a long, complex conditional is
> understanding the structure of the operators, not the operands.

Since there's a mix of pre-, post- and infix, the structure of the
operators _depends on_ the operands.

> However, there's a lot of difference of opinion on this (perhaps
> rooted in differences in cognition and reading behavior). For me it's
> not even close - expressions broken so the operators are at the head
> of the line snap into focus and those with operators at the ends of
> the lines look like undifferentiated goo. Since some of the style

I'm exactly opposite; the "uncorrected" line above is a typo because
there's no continuation item at the end of the line. I don't even see
the following lines because they are, by definition, not part of the
code I'm looking at. Leaving the operators at the end of the line I
easily see that it's a binary operator, and there's no second operand
so the next line must contain it, parse the next line as well.

Hm. I didn't realise this but the unspoken underlying factor for me is
the "one instruction per line" style. If you must break over multiple
lines, there must be a continuation item to indicate that. This is how
I detect missing semicolons.

..Stu


WARNING: multiple messages have this Message-ID (diff)
From: "Stuart MacDonald" <stuartm@connecttech.com>
To: "'Satyam Sharma'" <satyam.sharma@gmail.com>,
	"'Andrew Morton'" <akpm@linux-foundation.org>
Cc: "'Christoph Hellwig'" <hch@infradead.org>,
	"'Roland McGrath'" <roland@redhat.com>,
	"'Christoph Hellwig'" <hch@lst.de>,
	<linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>
Subject: RE: condingstyle, was Re: utrace comments
Date: Tue, 1 May 2007 12:15:00 -0400	[thread overview]
Message-ID: <001601c78c0b$deb12a30$294b82ce@stuartm> (raw)
In-Reply-To: <a781481a0704301142sfec317cu8213750c9ab84416@mail.gmail.com>

From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
               ^^^^^^^^^^^^^^^^^^^^^^^
> 
> 	if (veryverylengthycondition1 &&
> 		smallcond2 &&
> 		(conditionnumber3a ||
> 		condition3b)) {
> 		...
> 	}
> 
> versus

Whoops! You've got an unterminated if there, let me fix it up...

> 	if (veryverylengthycondition1) {
> 	    && smallcond2
> 	    && (conditionnumber3a
> 	        || condition3b)) {
> 		...
> 	}> 

From: On Behalf Of Scott Preece
> I still find the leading-operator style much more readable. The most
> important thing in reading a long, complex conditional is
> understanding the structure of the operators, not the operands.

Since there's a mix of pre-, post- and infix, the structure of the
operators _depends on_ the operands.

> However, there's a lot of difference of opinion on this (perhaps
> rooted in differences in cognition and reading behavior). For me it's
> not even close - expressions broken so the operators are at the head
> of the line snap into focus and those with operators at the ends of
> the lines look like undifferentiated goo. Since some of the style

I'm exactly opposite; the "uncorrected" line above is a typo because
there's no continuation item at the end of the line. I don't even see
the following lines because they are, by definition, not part of the
code I'm looking at. Leaving the operators at the end of the line I
easily see that it's a binary operator, and there's no second operand
so the next line must contain it, parse the next line as well.

Hm. I didn't realise this but the unspoken underlying factor for me is
the "one instruction per line" style. If you must break over multiple
lines, there must be a continuation item to indicate that. This is how
I detect missing semicolons.

..Stu


  parent reply	other threads:[~2007-05-01 16:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-27 16:51 utrace comments Christoph Hellwig
2006-12-05  9:51 ` Roland McGrath
2006-12-06 21:58   ` Christoph Hellwig
2007-04-30  4:02 ` Roland McGrath
2007-04-30  9:08   ` Christoph Hellwig
2007-04-30  9:18     ` Russell King
2007-04-30  9:22       ` Christoph Hellwig
2007-04-30  9:33         ` Russell King
2007-04-30  9:45           ` Russell King
2007-04-30 10:32             ` Christoph Hellwig
2007-04-30 10:18           ` Christoph Hellwig
2007-06-22  2:40           ` Roland McGrath
2007-05-10  8:49     ` Roland McGrath
2007-04-30  9:11   ` condingstyle, was " Christoph Hellwig
2007-04-30 17:09     ` Andrew Morton
2007-04-30 18:19       ` Jan Engelhardt
2007-04-30 18:39       ` Daniel Hazelton
2007-04-30 18:42       ` Satyam Sharma
2007-04-30 22:18         ` Stefan Richter
2007-05-01  9:00         ` Geert Uytterhoeven
2007-05-01 13:11           ` Scott Preece
2007-05-01 14:16           ` David Woodhouse
2007-05-01 15:00             ` John Anthony Kazos Jr.
2007-05-01 16:07               ` David Howells
2007-05-02  2:18                 ` Eric W. Biederman
2007-05-02  9:32                   ` David Howells
2007-05-02  9:32                     ` David Howells
2007-05-02 11:55                     ` Eric W. Biederman
2007-05-02 12:05                       ` David Howells
2007-05-02 12:05                         ` David Howells
2007-05-01 20:12               ` Satyam Sharma
2007-05-01 15:05             ` Randy Dunlap
2007-05-01 15:06               ` David Woodhouse
2007-05-01 20:44                 ` Satyam Sharma
2007-05-01 15:07             ` Geert Uytterhoeven
2007-05-01 15:11               ` David Woodhouse
2007-05-01 16:15         ` Stuart MacDonald [this message]
2007-05-01 16:15           ` Stuart MacDonald
2007-04-30 21:34       ` Luck, Tony
2007-04-30 21:34         ` Luck, Tony

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='001601c78c0b$deb12a30$294b82ce@stuartm' \
    --to=stuartm@connecttech.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=satyam.sharma@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.