Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exspes From: exspes@gdr.bath.ac.uk (P E Smee) Newsgroups: comp.lang.c Subject: Re: common bugs in C programs Message-ID: <1990Jan3.095204.6979@gdt.bath.ac.uk> Date: 3 Jan 90 09:52:04 GMT References: <61500001@uicbert.eecs.uic.edu> <5860@umd5.umd.edu> Reply-To: exspes@gdr.bath.ac.uk (P E Smee) Organization: University of Bristol c/o University of Bath Lines: 34 In article <5860@umd5.umd.edu> lgollub@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@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)