Assignment in test: OK?
Bruce Worden
bruce at seismo.gps.caltech.edu
Thu Sep 13 05:47:53 AEST 1990
In article <BURLEY.90Sep12073323 at world.std.com> burley at world.std.com (James C Burley) writes:
>The point is, casual reading of code containing a mistake like
>
> if (foo = 0)
>
>compared to an equivalent
>
> if (foo := 0)
>
>one can easily conclude the mistake is easier to find in the latter case.
If the `:=' is for assignment and `==' for comparison and both
if(foo := 0)
and
if(foo == 0)
are legal, I don't see how `:=' is any better than just `='. People who
are used to thinking of `:=' as `equal' will type it as freely as we
type `='. Only something like Fortran's .EQ. is different enough to
draw attention to the two different meanings of `is equal to'.
The following is a general comment and is not directed specifically at
Mr. Burley:
I have made the `if(x = y)' mistake myself, but it is always relatively
easy to find because I would never intentionally write that construct.
C gives us the ability to be extremely clever by writing things like:
while(thisfunc(a=(b++ * thatfunc(c=d--))))
...
but that doesn't mean we should do it. It might impress some people, but
it is extremely cryptic and there is usually a clearer way to write the
code to do the same thing. Likewise, if one always writes:
x = y;
if(x)
...
it is not as spiffy looking as `if(x = y)', but it is just as efficient to
execute and is unambiguous. I am not objecting to constructs like:
if((fd=open(path,flags,mode)) != NULL)
...
but, in those cases, I always make the comparison explicit.
--------------------------------------------------------------------------
C. Bruce Worden bruce at seismo.gps.caltech.edu
252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125
More information about the Comp.lang.c
mailing list