Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site oliveb.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!jerry From: jerry@oliveb.UUCP (Jerry Aguirre) Newsgroups: net.lang.c Subject: Use of i++; Re: C programming style Message-ID: <508@oliveb.UUCP> Date: Tue, 16-Jul-85 20:12:36 EDT Article-I.D.: oliveb.508 Posted: Tue Jul 16 20:12:36 1985 Date-Received: Thu, 18-Jul-85 06:11:25 EDT References: <11434@brl-tgr.ARPA> Organization: Olivetti ATC; Cupertino, Ca Lines: 65 > 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