Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!DHowell.ES@Xerox.ARPA From: DHowell.ES@Xerox.ARPA Newsgroups: net.lang.c Subject: more about programming style Message-ID: <11457@brl-tgr.ARPA> Date: Wed, 10-Jul-85 16:35:54 EDT Article-I.D.: brl-tgr.11457 Posted: Wed Jul 10 16:35:54 1985 Date-Received: Fri, 12-Jul-85 04:46:05 EDT Sender: news@brl-tgr.ARPA Lines: 56 Ok, let me clarify a few things here. By "idioms", I mean a piece of code in a language which can be directly translated into another piece of code in that ame language and looks similar in syntax to the same piece of code in many other languages. This would include i++ for i = i + 1 and if((a=b)==c) for a=b; if (a==c). Idioms are language-specific. These are the idioms that I would avoid to make programs more readable. Pointers are a programming feature, not necessarily specific to a language. While BASIC, FORTRAN, and APL don't have them per se, they could be simulated using procedures/subroutines. When confronted with two different ways of doing something in two different languages, the more understandable, the better. A pointer is generally easier to handle than a PEEK or POKE function. Structured programming is basic to the understandability of a program. If a language does not support structured programming, either the language should not be used, or it should be used very carefully with comments explaining the structure of the programming. Of course comments are important to any program, but they're not always all that is important to a good program. Let me give a possible scenario. Let's say I am a person whose programming experience consisted a few high school and college courses in Basic & Pascal. Ok, now let's say I have a problem that I want solved by a programmer. The programmer comes back to me with a program which doesn't do quite what I wanted. Now from the comments it looks like the program should work right. The problem is in the code. Now the programmer goes off and tries to fix it, thinking he knows exactly what I want. But when he comes back with the revised program, it still doesn't do what I wanted. Now the comments were not enough to understand why the program doesn't do what I wanted. Therefore I must look at the code ("Foul", I hear you say. "What are you doing looking at his code; you're not an experienced C programmer!" Well who else can look at it, if the programmer can't fix it himself? At least I know what I want done). The program turns out to be a full of these strange little idioms, which I've never seen before. Luckily, some of the code is readable, so I hope that what is wrong is in that. Let's say the problem with the program is that a variable is being incremented when it shouldn't be. However I don't know that the variable is being incremented because I see this cryptic "stuff++" which I pretty much ignore because the code is full of things like that which gets lost in the shuffle. I'm lost, the programmer doesn't know what's wrong, and we're stuck. However if the program said "stuff = stuff + 1" or even "increment(stuff)", I could say "Aha! I think I know why it's not working. That variable 'stuff', why is it being incremented. I don't think it should be incremented". The programmer removes that line, the program is fixed, and we all live happily ever after. I know this was a rather long story, but I had to get my point across somehow. Remember that the "I" in that story could be someone you will be working for. Dan