jerry@oliveb.UUCP (Jerry Aguirre) (07/17/85)
> Let me start out by saying that while I am not an experienced C > programmer, I am an experienced programmer. These replies are based on > my limited knowledge of C, but I believe they are applicable to all > programming languages in one way or another. . . > >Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to > >me, . . > to increment a variable. If I want to distinguish between incrementing > and adding, then I would define a procedure such as "increment(i)", > which can be immediately understood. > Dan /* comments are of course welcome */ Wants to define a "procedure" such as "increment(i)", claims to understand C, obviously doesn't! Could be done as a macro but never as a procedure. I have seen several projects coded in the "make it look like algol" style of programming. They define BEGIN to be { and END to be ;}, etc. It always seems to cause more trouble in the end than it saved. By the time they finished the project they are usually familiar enough with the language that they no longer need these crutches. Experienced C programmers get frustrated trying to follow the code because there is always this extra level of indirection that has to be verified as correct. I have at times refused to help users with "C problems" because figuring out whether the syntax is correct requires reading a 300 line header file that compleatly redefines the language. No, increment(i) is not clearer than i++; If I want to understand what i++ means I only have to check the language spec. Once I understand it I know more about the C language. If I come across an increment(i) then I am left in the dark. Is this built into the language, a "procedure" defined later in the code, in an included file, from a library? Is it defined correctly? Does it handle floats, longs, and ints? How can it change "i" when C has call by value? And after I figure out what increment(i) does then I have learned how one person coded one program. When I work on someone elses code I have to start all over and learn what "next(i)" does. Writting clear code is like driving. It doesn't matter whether you drive on the left or right side of the road. What matters is that you drive on the side people expect you to. If you want ease of maintenance then concentrate on USEFUL comments. My favorate non-comment is: int debug; /* true if debugging is enabled */ or the ever popular: i++; /* increment i */ Usually followed by a 3 page procedure with a cryptic name and no comments. I mean is it really hard to figure out what the variable debug is used for? I would really rather have a few lines at the top of each procedure telling what it does and what the arguments are. It is usually easy to follow the code if you know why the procedure was called. It's trying to follow the code when you don't know what it was called for or what its inputs are that is hard. Languages don't write bad code, people do. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry
franka@mmintl.UUCP (Frank Adams) (07/19/85)
In article <508@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >If you want ease of maintenance then concentrate on USEFUL comments. My >favorate non-comment is: > int debug; /* true if debugging is enabled */ >or the ever popular: > i++; /* increment i */ > >Usually followed by a 3 page procedure with a cryptic name and no >comments. I mean is it really hard to figure out what the variable >debug is used for? I would really rather have a few lines at the top >of each procedure telling what it does and what the arguments are. It >is usually easy to follow the code if you know why the procedure was >called. It's trying to follow the code when you don't know what it was >called for or what its inputs are that is hard. Broadly speaking, I agree with this. But you should go a step further, (especially for a 3+ page procedure) and put a comment at the top of each logical section of the code. This makes it easier to read the code and figure out what the program does. A comment on each line doesn't (much) do this, because one can as easily read the code as the comments. Only obscure statements need comments, which is why one puts a comment on every line in assembler code. (! :-) >Languages don't write bad code, people do. Yes, but some languages make it easy to write good code, and hard to write bad code, while others do the opposite. > Jerry Aguirre @ Olivetti ATC >{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry Frank Adams
itkin@luke.UUCP (Steven List) (07/20/85)
Having read through much of the recent discussion, I'm amused by one
omission: ++i (and it's relatives)! The original poster (at least I
think it was the original) suggests a function (or macro)
"increment(i)". The function/macro approach does not deal with the
sequence of events. The nominal case of incrementing a variable in a
simple expression
i++;
is trivial. How about in a loop:
char buf[80];
char *cp = buf;
/* always leave the first character alone */
while (*(++cp));
searching for the first NUL in a string. This is not necessarily a
useful example, but does demonstrate the case. How do you use the
function/macro? It requires more statements and is not as clear, to me.
I've been told that I write/understand cryptic C. This is not cryptic
to me. It is concise and clear. What's the objection to using the
language as designed? Why NOT use features?
--
***
* Steven List @ Benetics Corporation, Mt. View, CA
* Just part of the stock at "Uncle Bene's Farm"
* {cdp,greipa,idi,oliveb,sun,tolerant}!bene!luke!itkin
***