Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site reed.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!reed!alexis
From: alexis@reed.UUCP (Alexis Dimitriadis)
Newsgroups: net.lang.c
Subject: Re: more about programming style
Message-ID: <1693@reed.UUCP>
Date: Wed, 17-Jul-85 04:22:40 EDT
Article-I.D.: reed.1693
Posted: Wed Jul 17 04:22:40 1985
Date-Received: Fri, 19-Jul-85 02:17:09 EDT
References: <11457@brl-tgr.ARPA> <68@ucbcad.UUCP>
Reply-To: alexis@reed.UUCP (Alexis Dimitriadis)
Organization: Reed College, Portland, Oregon
Lines: 71
Summary: 

> [...] Besides, many people have pointed out that you
> sometimes have to be a bit obscure to get efficient code -- if you write
> 
> 	while (p->duck)
> 		p++;
> 
> instead of
> 
> 	while (p++->duck)
> 		;
> 
> you are likely not to get the loop compiled with auto-increment instructions.

  (giggle) 
  As any "pro" must have noticed, the two versions given will
not do the same thing.  Whose side are you on, anyway?  :-)

  Seriously, C is always being derided for having terse operators whose
functions are not immediately obvious.  "{" and "}" are comment delimiters
in Pascal.  Should I "#define begin {" for better readability?  
Using the _basic_ features of C as intended by the implementers should
be prefectly acceptable to everyone.

  Expressions like "while (var++) ;" introduce problems that take
(bitter) experience before they can be handily detected, even if the
reader is familiar with the semantics of the expression.  That is the
real reason it takes a seasoned C programmer to debug seasoned C code.

  On the other hand, C programmers have enough to worry about, what
with portability considerations and readability to other _experienced_ 
C programmers, not to mention efficiency.  If you can't please
everyone, you might as well cater to those who are most likely to
benefit from being able to read your program.  (i.e., those who could
do something useful to it after they understand it).

  And finally, about "if ((fp=fopen("file", "r")) == NULL)", et al.
I find the idiom is an excellent aid to ensuring that the variable returned
by the test WILL be used.  Not applicable to "professional" work, you say.
Haven't you ever been tempted to skip tests that "never" return true?  It
is easier to do if the test is a separate statement that could just as well
be skipped (or forgotten!).  As it is, I think fopen() looks funny when 
it is called WITHOUT an enclosing if() test.  Idioms like that are a 
good way of always doing things the same way.  It may look confusing the
first time, but it's reassuring after the twentieth...

I sympathize with those trying to comprehend C idioms, but at least they
are language features, if used in a fairly consistent manner, and there 
are real benefits to be gained from their consistent use.  

Alexis Dimitriadis
	alexis @ reed
----------------------
  Disclaimer:  I routinely use, (but with no misconceptions about its 
clarity), code like
		...
		switch (*++*argv) {
		...
to read the next character in an option argument.  (yes, I did finally 
get a public-domain getopt, I will be using it).  I am generally proud
of the readability of my code.
-- 
_______________________________________________
  As soon as I get a full time job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.

             alexis @ reed

	         ...teneron! \
...seismo!ihnp4! - tektronix! - reed.UUCP
     ...decvax! /