typedefs, etc.
    Jim Reuter 
    jreuter at cincy.UUCP
       
    Wed Dec 28 09:19:04 AEST 1983
    
    
  
I agree with almost everything Steve Summit (azure!stevesu) has to
say about typedefs, readability, and other things, but I strongly
disagree with the following statement:
	...
	I once had points taken off on a programming assignment for
	writing something like
		if(a == b) return(TRUE);
		else return(FALSE);
	The grader said I should have "more succinctly" said
		return(a == b);
	I realize now that he was wrong, and I wish I'd realized it then,
	and called him on it.  He was obviously a fully indoctrinated
	member of the "hacks are beautiful" school.  Those two fragments
	do do the same thing, and this is a case where the second one
	might even generate slightly more efficient code.  But I have to
	look at something like "return(a == b)" twice or even three times
	to convince myself that it's identical to what I conceptualize as
	"if a equals b it's true, otherwise it's not."  Why make things
	difficult?  I know the idiom, and it still gets in my way. 
	...
I think his confusion may arise from the fact that in C, boolean values
are integers.  In some programming languages, booleans are completely
separate from integer types, and one can declare a function of boolean
type that will return TRUE or FALSE as the result of a boolean
(comparison) operation.  In fact, this is just what boolean operators
are.
Perhaps if he used the much discussed typedef, and wrote
	typedef int BOOL;
	BOOL
	somefunc( a, b )
	int a,b;
	{
		return( a == B );
	}
things would seem clearer.  I disagree with his statement that his
first example is clearer, and I can show several examples of
similar constructs which are definitely NOT clearer:
	c = a > b ? a : b;
	is worse than
	#define	max(a,b) (a > b ? a : b)
	c = max( a, b );
or perhaps
	if (i == 5)
		i = 6;
	if (i == 4)
		i = 5;
	if (i == 3)
		i = 4;
	if (i == 2)
		i = 3;
	if (i == 1)
		i = 2;
	is far worse than
	i = i + 1;
	or even
	i++;
This last example I saw three years ago in an article about some
programming atrocities that real, practicing, "professional programmers"
were commiting.  It was written by a manager of a programming staff.
I realize it is a bit extreme, but it is of the same style.
    
    
More information about the Comp.unix
mailing list