Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!tmb From: tmb@talcott.UUCP (Thomas M. Breuel) Newsgroups: net.lang.c Subject: Re: Style, readability, etc. Message-ID: <471@talcott.UUCP> Date: Fri, 26-Jul-85 01:02:42 EDT Article-I.D.: talcott.471 Posted: Fri Jul 26 01:02:42 1985 Date-Received: Sun, 28-Jul-85 08:51:19 EDT References: <95@brl-tgr.ARPA> Organization: Harvard University Lines: 72 > Here is my basic opinion: Programs should be as readable as possible so > that people who need to look at the code can understand it easily. If a Great. I love readable programs. Why don't you start indenting by 8 spaces, put your braces on the same line as the conditional, and make frequent use of '++' and if((c=getchar())!='\n'). And don't use comments. Seriously, readability is a purely personal matter. I vastly prefer programs that are dense, i.e. in which I can see lots of code on a single page. Other people prefer explanatory comments and to balance their braces by putting them on individual lines. > I have stated that i = i + 1 was more readable than i++. The reason is > that i = i + 1 is a standard seen in many languages (only the assignment The expression (sic) 'i=i+1' is wrong if you consider it from a mathematical point of view (i.e. grammar school math), but you nevertheless got so used to it that you consider it 'readable' and 'natural'. This shows that you (and probably others) are pretty flexible in terms of syntax. > while(ptr++->duck) /* move pointer to the duck after the next NULL */ > ; > [...] > but if efficiency is your thing, then [this] one is ok > *AS LONG AS THE COMMENT IS THERE*. You present the example of an idiom that is taught (or should be taught) to any beginner in 'C'. Understanding a programming language does not mean that you only understand its syntax or its semantics, but that you also know its idioms by heart, much as you don't 'speak' a natural language until you understand its idioms and figures of speech without explanatory remarks. (BTW, I DON'T LIKE isolated semicolons, I find that they are BAD STYLE... Also, your comment doesn't make much sense to me, whereas your code does). > And don't worry about efficiency until the program works! Agreed, that's perfectly reasonable. But programmers (at least the ones I know) don't use compact notation in 'C' because they think it is more efficient (sometimes it is not), but because it expresses things concisely. > To demonstrate, I am currently working on a program, written by someone > else, written in Mesa, a language similar to Pascal, but much more > modular. The language is very readable as languages go. The program > has very few comments. (The majority of comments are the kind "END; > --of DisplayProc"; really helpful, eh?) I think how much easier the Understanding someone else's code is always work. I like code most which describes the purpose, input, output, and side-effects of each procedure but comments procedure bodies only very sparsely. But, again, that is a matter of opinion, not of absolute truth. Altogether: understanding someone else's program is always work. It is easier if that person happens to have the same programming style that you do. Usually that is not the case. Don't curse other people for using what they consider the best way to layout their programs, they probably have good reasons for it. Now, you can start discussions about whether it is better to indent by three or by eight spaces, whether it is better to balance braces with braces or control statements, whether it is better to use this or that idiom, and so on, but you are likely not to find much sympathy and not to have too much success to generate a standard. Thomas. PS: Personally, I am in the lucky position that a like 'cb', that I know 'sed', and that I dislike comments, and that I therefore can put programs into 'my style' rather easily (it is easy to remove comments automatically, but hard to add them...).