public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: gcc@gcc.gnu.org
Cc: "James K. Lowden" <jklowden@freetds.org>,
	 Ian Lance Taylor <iant@google.com>
Subject: Re: -Wparentheses lumps too much together
Date: Thu, 20 Dec 2007 16:41:00 -0000	[thread overview]
Message-ID: <200712201509.20582.paul@codesourcery.com> (raw)
In-Reply-To: <20071220005030.4971a442.jklowden@freetds.org>

> My untested (and consequently firmly
> held) hypothesis is that
>
> 1) most combinations of && and || don't need parentheses because
>
> 	(a && b) || (c && d)
>
> is by far more common than
>
> 	a && (b || c) && d
>
> and, moreover, broken code fails at runtime, and

I dispute these claims.

The former may be statistically more common, but I'd be surprised if the 
difference is that big. I can think of several fairly common situations where 
both would be used.

Any time you've got any sort of nontrivial condition, I always find it better 
to include the explicit parentheses. Especially if a, b, c, and d are 
relatively complex relational expressions rather than simple variables.

Code failing at runtime is way too late.  By that time it's already been 
burned onto the device, and may be half way to the moon :-)
Coverage testing never tests everything, and there's a fair chance that your 
complex condition will only break in an exceptional case which is, by 
definition, hard to predict, test and reproduce.

> 2) Most programmers know (because they need to know) that && comes
> before ||. 

I don't really believe that either. Most *good* programmers know operator 
precedence rules (or will at least look it up). However there are a lot of 
distinctly average programmers, and even the good programmers get confused or 
have bad days. As someone else mentioned precedence of arithmetic operators 
is taught in school from a fairly early age. Precedence of logical operators 
is (to me at least) much less well conditioned.


I have no objection to splitting -Wparentheses into finer grained options. I 
just think they should remain enabled by -Wall.

Paul

  reply	other threads:[~2007-12-20 15:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-19 20:07 jklowden
2007-12-19 20:14 ` Doug Gregor
2007-12-19 20:39   ` Ismail Dönmez
2007-12-19 20:15 ` Daniel Jacobowitz
2007-12-19 23:11 ` Ian Lance Taylor
2007-12-20  6:08   ` James K. Lowden
2007-12-20 16:41     ` Paul Brook [this message]
2007-12-21 20:19       ` Ross Smith
2008-01-11  7:34         ` Rehno Lindeque
2008-01-11 17:00           ` Joe Buck
2008-01-11 17:05             ` Robert Dewar
2008-01-11 23:26             ` Ian Lance Taylor
2008-01-12  0:50               ` Joe Buck
2007-12-20 18:01     ` Ian Lance Taylor
2007-12-21  5:28       ` James K. Lowden
2007-12-21  9:27 ` Ralf Wildenhues
2007-12-21 17:16   ` NightStrike
2008-01-11 22:44 ` Doug Gregor
2008-01-12  3:48   ` Ian Lance Taylor
2008-01-12 10:16     ` Andreas Schwab
2008-01-12 11:23       ` Paolo Bonzini
2008-01-13 16:03     ` Gabriel Dos Reis
2008-03-10 17:25 Derek M Jones

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=200712201509.20582.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=jklowden@freetds.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).