Re: how to let gcc warn me when I use = in conditions

Discussion in 'C++' started by Alfred Z. Newmane, Jun 24, 2005.

  1. Stan R. wrote:
    > wrote:
    >> Hi,
    >>
    >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    >> there any way the gcc compiler can give me a warning?

    >
    > What version are you using?


    From what I've seen, both 2.9x and 3.x behave the same way in this
    respect.
     
    Alfred Z. Newmane, Jun 24, 2005
    #1
    1. Advertising

  2. Alfred Z. Newmane

    Greg Guest

    Alfred Z. Newmane wrote:
    > Stan R. wrote:
    > > wrote:
    > >> Hi,
    > >>
    > >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    > >> there any way the gcc compiler can give me a warning?

    > >
    > > What version are you using?

    >
    > From what I've seen, both 2.9x and 3.x behave the same way in this
    > respect.


    You can also get in the habit of placing the rvalue (or constant value)
    on the left of a comparison expression:

    if (0 == myVar)
    {
    ...
    }

    Now the code won't compile if a = replaces the ==.

    Greg
     
    Greg, Jun 24, 2005
    #2
    1. Advertising

  3. * Greg:
    >
    >
    > Alfred Z. Newmane wrote:
    > > Stan R. wrote:
    > > > wrote:
    > > >> Hi,
    > > >>
    > > >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    > > >> there any way the gcc compiler can give me a warning?
    > > >
    > > > What version are you using?

    > >
    > > From what I've seen, both 2.9x and 3.x behave the same way in this
    > > respect.

    >
    > You can also get in the habit of placing the rvalue (or constant value)
    > on the left of a comparison expression:
    >
    > if (0 == myVar)
    > {
    > ...
    > }
    >
    > Now the code won't compile if a = replaces the ==.


    Although I won't recommend it, and it's formally Undefined Behavior, it's
    possible to #define the words 'if' and 'while' so that they require a 'bool'
    argument; that will catch many but not all '=='/'=' typos.

    From a readability perspective this left-side thing is awkward and unnatural.

    From the perspective of catching typos and mishaps, it's prone to the same kind
    of errors it's meant to catch... ;-)

    The best advice I know is to be very careful when writing code, and to TEST.

    Just my 3c.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Jun 24, 2005
    #3
  4. Alfred Z. Newmane

    Greg Guest

    Alfred Z. Newmane wrote:
    > Stan R. wrote:
    > > wrote:
    > >> Hi,
    > >>
    > >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    > >> there any way the gcc compiler can give me a warning?

    > >
    > > What version are you using?

    >
    > From what I've seen, both 2.9x and 3.x behave the same way in this
    > respect.


    You would want to compile with the -Wparentheses command line option.

    Greg
     
    Greg, Jun 24, 2005
    #4
  5. >>You can also get in the habit of placing the rvalue (or constant value)
    >>on the left of a comparison expression:
    >> if (0 == myVar)

    > From a readability perspective this left-side thing is awkward and unnatural.


    I hear this argument quite often, but after giving it a try I got used to it.

    It's quite rare that it points out a =/== mistake, but (imo) it could even aid reading:
    if (0 = aNotTooShortFunction( argument1, argument2, argument3 ))
    if you have a couple of these, there's no "eye-work" to get the point...
    .... assuming that the function name indicates it's type of result.
    Otherwise the value is placed far from the function name and just floating somewhere on the right.

    Similar to this I've heard the "?:" criticised a lot for readibility/understandability problems.
    Same for "++". And after all what the heck is "i = 1;" isn't it 'i equals 1'? ;-]
     
    =?ISO-8859-1?Q?Bal=E1zs_Szalai?=, Jun 24, 2005
    #5
  6. On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:

    >
    >
    > Alfred Z. Newmane wrote:
    >> Stan R. wrote:
    >> > wrote:
    >> >> Hi,
    >> >>
    >> >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    >> >> there any way the gcc compiler can give me a warning?
    >> >
    >> > What version are you using?

    >>
    >> From what I've seen, both 2.9x and 3.x behave the same way in this
    >> respect.

    >
    > You can also get in the habit of placing the rvalue (or constant value)
    > on the left of a comparison expression:
    >
    > if (0 == myVar)
    > {
    > ...
    > }
    >
    > Now the code won't compile if a = replaces the ==.


    However this is an incomplete solution (you don't always have a non-lvalue
    available) that results in less readable and less consistent code. Many
    compilers will diagnose this given suitable options and there are other
    "lint" tools available which will do so. This is much more relaible than
    source tricks like that above and is a much better approach.

    Lawrence
     
    Lawrence Kirby, Jun 24, 2005
    #6
  7. In article <>,
    Lawrence Kirby <> wrote:
    >On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:
    >
    >>
    >>
    >> Alfred Z. Newmane wrote:
    >>> Stan R. wrote:
    >>> > wrote:
    >>> >> Hi,
    >>> >>
    >>> >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    >>> >> there any way the gcc compiler can give me a warning?
    >>> >
    >>> > What version are you using?
    >>>
    >>> From what I've seen, both 2.9x and 3.x behave the same way in this
    >>> respect.

    >>
    >> You can also get in the habit of placing the rvalue (or constant value)
    >> on the left of a comparison expression:
    >>
    >> if (0 == myVar)
    >> {
    >> ...
    >> }
    >>
    >> Now the code won't compile if a = replaces the ==.

    >
    >However this is an incomplete solution (you don't always have a non-lvalue
    >available) that results in less readable and less consistent code. Many
    >compilers will diagnose this given suitable options and there are other
    >"lint" tools available which will do so. This is much more relaible than
    >source tricks like that above and is a much better approach.
    >
    >Lawrence


    Wow. For once, I agree with Lawrence Kirby.
    Well done, sir.
     
    Kenny McCormack, Jun 26, 2005
    #7
  8. Alfred Z. Newmane

    Greg Guest

    Lawrence Kirby wrote:
    > On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:
    >
    > >
    > >
    > > Alfred Z. Newmane wrote:
    > >> Stan R. wrote:
    > >> > wrote:
    > >> >> Hi,
    > >> >>
    > >> >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    > >> >> there any way the gcc compiler can give me a warning?
    > >> >
    > >> > What version are you using?
    > >>
    > >> From what I've seen, both 2.9x and 3.x behave the same way in this
    > >> respect.

    > >
    > > You can also get in the habit of placing the rvalue (or constant value)
    > > on the left of a comparison expression:
    > >
    > > if (0 == myVar)
    > > {
    > > ...
    > > }
    > >
    > > Now the code won't compile if a = replaces the ==.

    >
    > However this is an incomplete solution (you don't always have a non-lvalue
    > available) that results in less readable and less consistent code. Many
    > compilers will diagnose this given suitable options and there are other
    > "lint" tools available which will do so. This is much more relaible than
    > source tricks like that above and is a much better approach.
    >
    > Lawrence


    Absolutely, switching the left and right sides of an equality test as
    it is conventionally written makes the expression less readable [until
    the pattern becomes familiar]. The more readable the code, the more
    likely its errors will be overlooked. "Readable" text describes text
    that fits a familiar pattern, and which the brain can read faster
    because it can skip many of the words by filling in their most likely
    form and meaning. In this case an assignment expression can "read" like
    an equality test, so the mistake can go undetected.

    Note that switching the right and left operands makes the expression no
    less understandable. Source code should be written to be
    understandable, posts to USENET should be written to be readable. The
    computer does not execute a source program as if it were reading a
    novel. So a person reading the source of a program, should not read it
    in the same way as they would a novel.

    There are benefits to a less readable syntax even in the case when the
    left hand expression is not a constant. The brain will have to scan the
    expression much more closely (because it does not fit the expected
    pattern), in order to parse it. And the closer scrutiny is more likely
    to catch an assignment error.

    The motivation to write readable code is to lighten the workload on its
    reader; but it does so by essentially inviting the reader to gloss over
    its mistakes. The computer executing the code will overlook no error;
    so the reader should approach the source code as the computer does and
    have to examine each line to understand its meaning. Because whether a
    set of source code is readable or not, matters far less than whether it
    is understandably correct.

    Greg
     
    Greg, Jun 26, 2005
    #8
  9. In article <>,
    Greg <> wrote:
    ....
    >> However this is an incomplete solution (you don't always have a non-lvalue
    >> available) that results in less readable and less consistent code. Many
    >> compilers will diagnose this given suitable options and there are other
    >> "lint" tools available which will do so. This is much more relaible than
    >> source tricks like that above and is a much better approach.
    >>
    >> Lawrence

    >
    >Absolutely, switching the left and right sides of an equality test as
    >it is conventionally written makes the expression less readable [until
    >the pattern becomes familiar]. The more readable the code, the more
    >likely its errors will be overlooked. "Readable" text describes text
    >that fits a familiar pattern, and which the brain can read faster
    >because it can skip many of the words by filling in their most likely
    >form and meaning. In this case an assignment expression can "read" like
    >an equality test, so the mistake can go undetected.


    Very interesting. (Rest of very eloquent defense of your very clearly
    non-mainstream position - deleted only to save space)

    Mainstream thought today is that source code should be *readable* by humans
    and *understandable* by computers. This is so that you can spend less on
    humans.

    My $.02: People who maintain the converse of your (Greg's) position should
    not be programming in C. (*)

    (*) Read this carefully - this is not a typo.

    P.S. If you really care about this "problem" (which hasn't been a problem
    for me since about the 3rd week of my time as a C programmer), just do:

    #define EQUALS ==

    and use that for equality tests.

    P.P.S. This discussion is antique anyway, since every (*) C compiler since
    about 1989 has issued a warning about this (yes, sometimes you do have to
    find the right compiler option for it)

    (*) Don't bother writing in with obscure exceptions to this generalization.
     
    Kenny McCormack, Jun 26, 2005
    #9
  10. In article <>,
    Greg <> wrote:
    >There are benefits to a less readable syntax even in the case when the
    >left hand expression is not a constant. The brain will have to scan the
    >expression much more closely (because it does not fit the expected
    >pattern), in order to parse it. And the closer scrutiny is more likely
    >to catch an assignment error.


    >The motivation to write readable code is to lighten the workload on its
    >reader; but it does so by essentially inviting the reader to gloss over
    >its mistakes. The computer executing the code will overlook no error;
    >so the reader should approach the source code as the computer does and
    >have to examine each line to understand its meaning.


    Say, in your opinion, which font is best for your APL programs?
    --
    'The short version of what Walter said is "You have asked a question
    which has no useful answer, please reconsider the nature of the
    problem you wish to solve".' -- Tony Mantler
     
    Walter Roberson, Jun 26, 2005
    #10
  11. Alfred Z. Newmane

    Alan Balmer Guest

    On 26 Jun 2005 06:52:00 -0700, "Greg" <> wrote:

    >
    >
    >Lawrence Kirby wrote:
    >> On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:
    >>
    >> >
    >> >
    >> > Alfred Z. Newmane wrote:
    >> >> Stan R. wrote:
    >> >> > wrote:
    >> >> >> Hi,
    >> >> >>
    >> >> >> Sometimes, I write = instead of == in if conditions by mistakes. Is
    >> >> >> there any way the gcc compiler can give me a warning?
    >> >> >
    >> >> > What version are you using?
    >> >>
    >> >> From what I've seen, both 2.9x and 3.x behave the same way in this
    >> >> respect.
    >> >
    >> > You can also get in the habit of placing the rvalue (or constant value)
    >> > on the left of a comparison expression:
    >> >
    >> > if (0 == myVar)
    >> > {
    >> > ...
    >> > }
    >> >
    >> > Now the code won't compile if a = replaces the ==.

    >>
    >> However this is an incomplete solution (you don't always have a non-lvalue
    >> available) that results in less readable and less consistent code. Many
    >> compilers will diagnose this given suitable options and there are other
    >> "lint" tools available which will do so. This is much more relaible than
    >> source tricks like that above and is a much better approach.
    >>
    >> Lawrence

    >
    >Absolutely, switching the left and right sides of an equality test as
    >it is conventionally written makes the expression less readable [until
    >the pattern becomes familiar]. The more readable the code, the more
    >likely its errors will be overlooked.


    So, once the pattern becomes familiar, it's just as likely the error
    will be overlooked? Why bother?

    >"Readable" text describes text
    >that fits a familiar pattern, and which the brain can read faster
    >because it can skip many of the words by filling in their most likely
    >form and meaning. In this case an assignment expression can "read" like
    >an equality test, so the mistake can go undetected.


    Nope. As you say, the brain recognizes patterns. "A = B" is a
    different pattern from "A == B", and sticks out like the proverbial
    sore thumb.
    >
    >Note that switching the right and left operands makes the expression no
    >less understandable. Source code should be written to be
    >understandable, posts to USENET should be written to be readable. The
    >computer does not execute a source program as if it were reading a
    >novel. So a person reading the source of a program, should not read it
    >in the same way as they would a novel.


    If this actually means anything, I think you should present it to
    Donald Knuth ;-)
    >
    >There are benefits to a less readable syntax even in the case when the
    >left hand expression is not a constant. The brain will have to scan the
    >expression much more closely (because it does not fit the expected
    >pattern), in order to parse it. And the closer scrutiny is more likely
    >to catch an assignment error.
    >
    >The motivation to write readable code is to lighten the workload on its
    >reader; but it does so by essentially inviting the reader to gloss over
    >its mistakes. The computer executing the code will overlook no error;
    >so the reader should approach the source code as the computer does and
    >have to examine each line to understand its meaning.


    Or, perhaps, allow the computer to do the job?

    > Because whether a
    >set of source code is readable or not, matters far less than whether it
    >is understandably correct.
    >
    >Greg


    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Jun 27, 2005
    #11
  12. Alfred Z. Newmane

    CBFalconer Guest

    Alan Balmer wrote:
    > "Greg" <> wrote:
    >

    .... snip ...
    >>
    >> Absolutely, switching the left and right sides of an equality
    >> test as it is conventionally written makes the expression less
    >> readable [until the pattern becomes familiar]. The more readable
    >> the code, the more likely its errors will be overlooked.

    >
    > So, once the pattern becomes familiar, it's just as likely the
    > error will be overlooked? Why bother?


    By the reader. The compiler, being less easily distracted, will
    notice.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Jun 27, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Luigi Donatello Asero

    Let or not let the text float

    Luigi Donatello Asero, Jan 15, 2004, in forum: HTML
    Replies:
    6
    Views:
    489
    Steve R.
    Jan 15, 2004
  2. Rolf Hemmerling
    Replies:
    2
    Views:
    566
    Nils Petter Vaskinn
    Nov 18, 2003
  3. Replies:
    65
    Views:
    1,190
    Rob Thorpe
    Aug 25, 2005
  4. Cuthbert
    Replies:
    89
    Views:
    1,346
    Michael Wojcik
    Sep 11, 2006
  5. David Resnick
    Replies:
    8
    Views:
    380
    robin
    Nov 18, 2010
Loading...

Share This Page