common bugs in C programs

[P E Smee]

In article <5860 at umd5.umd.edu> lgollub at umd5.umd.edu (Lewis R. Gollub) writes:
>     They propose using the preprocessor to define various substitutions
>of standard C code for more easily read programmer's code.
>     In this case you would include a line
>
>#define EQ ==
>      if (a EQ b)
>
>     This elegant (or inelegant, dependning on your sphistication and
>your adherence to "standards") might help someone transferring to C
>from Fortran, or with less programming background, and makes the prgogram
>easier to read for a non-C programmer.
>
>     Although  I don't code this way, I'd like to hear pro and con arguments
>on this strategy.

I keep a copy of their 'easy_c.h' lying around as an example of what
the preprocessor can do, but I don't actually approve of the use of
this technique.  While it can make reading the code easier for the
person who is accustomed to using it, it suffers from several
shortcomings, which are in my opinion fairly major.

First, it makes the code much harder to read for people who DON'T use
this approach -- like, probably, whoever takes over maintenance of your
code.  Second, it keeps the user of the technique from becoming
familiar with 'raw' C, and so makes it harder for them to take over
code belonging to other people.  And, third (but contributing to both
of those) some of the constructs they provide have the effect of
changing the APPARENT syntax of the language, so providing room for
confusion.

-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee at bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)