C programming syle poll
John Hobson
amigo at iwlc6.UUCP
Tue Apr 24 05:57:34 AEST 1984
Last friday, I got a new book entitled C PROGRAMER'S LIBRARY by
Jack J. Purdum, Timothy C. Leslie, and Alan L. Stegemoller
(Indianapolis: Que Corporation, 1984). I wish to quote the
following from pp 11 and 12:
Examine the program segment in Figure 0.4.
_____________________________________________________
Figure 0.4
y = 0;
if(x == 5)
y = 1;
_____________________________________________________
The code in this figure sets the variable y equal to 1 if x
equals 5. Otherwise, the value of y will be 0. Nothing is
wrong with the code; it will execute properly. A more
knowledgeable C programmer, however, will probably use the
code in Figure 0.5.
_____________________________________________________
Figure 0.5
y = (x == 5) ? 1 : 0;
_____________________________________________________
In Figure 0.5, the programmer used the ternary operator to
accomplish the same task. The difference between the two
examples comes from programming expertise. The second
example reflects more expertise in C and generates less
code.
In Figure 0.6, a third code reveals an even greater
knowledge of C.
_____________________________________________________
Figure 0.6
y = x == 5;
_____________________________________________________
This code produes the same result as the previous two, but
it relies on a good understanding of the hierarchy of C
operators. Becuase the test for equality (==) has higher
precedence than assignment, the comparison of x to 5 is
performed first. If the test is logic True (that is, x
does equal 5), then y is assigned the value of 1. If x
does not equal 5, the test is logic False, and y is
assigned the value of 0.
The code in Figure 0.6 does not involve any compiler-specific
tricks. All C compilers should produce the same results.
This code simply reflects more expertise in C and usually
generates less code.
You may argue that the first two examples are more
"readable" than that of Figure 0.6. When pressed for an
operational definition of readable, you may say that the
intent of the code is clearer in the first two examples.
This argument, however, assumes a level of expertise on the
part of the person who is reading the code. Although an
inexperienced C programmer may need time to understand what
the code y=x==5 is doing, and experienced C programmer will
understand the code immediately.
Indeed, the experienced C programmer probably uses the
technique illustrated in the last example so often that it
is more obvious than the other two forms.
All right, all you experienced C programmers out there. I am
curious to know which version you would use. My personal
preference is towards version 2 (y = (x == 5) ? 1 : 0). I agree
that version 1 is a bit simplistic, and so is another alternative:
if (x == 5)
y = 1;
else
y = 0;
however, they are easy to understand.
I do not like version 3 (y = x == 5). First of all, according to
The Sacred Text (Section 3.2) a logical False has a zero value, but
a logical True just has a NON-ZERO value, not necessarily equal to 1.
However, my main objection is that version 3 is not clear.
Kernighan and Plauger, in THE ELEMENTS OF PROGRAMMING STYLE, say
(p. 2) "write clearly -- don't be clever". After all, the person
who has to maintain the code may be a neophyte. Perhaps y=x==5
would be good in the UNIX kernel (although even here I would
replace it with y = (x == 5) [note the parentheses]) where speed is
of the essence, but in an applications program I would reject it.
Please send all responses to me, and I will summarize and post to
the net in a week or so.
John Hobson
AT&T Bell Labs--Naperville, IL
ihnp4!iwlc6!amigo
More information about the Comp.lang.c
mailing list