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.lang.c mailing list