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