«

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 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:
>
>
> 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?

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

>>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'? ;-]

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

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.

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

In article <. com>,
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.

In article <. com>,
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