Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site cyb-eng.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!utastro!cositex!cyb-eng!bc From: bc@cyb-eng.UUCP (Bill Crews) Newsgroups: net.lang.c Subject: Re: Re: Re: more questions about efficient C code Message-ID: <587@cyb-eng.UUCP> Date: Wed, 10-Jul-85 11:18:12 EDT Article-I.D.: cyb-eng.587 Posted: Wed Jul 10 11:18:12 1985 Date-Received: Sat, 13-Jul-85 08:48:47 EDT References: <474@crystal.UUCP> <397@umcp-cs.UUCP> <721@wlcrjs.UUCP> <5755@utzoo.UUCP> Organization: Cyb Systems, Austin, TX Lines: 51 >>> Rubbish. "Any experienced programmer should be able to understand that" >>> really means "we know it's hard to read, but...". The idea is to make >> >> No!, it does not mean that... > It is entirely possible to understand the semantics of the code fully and > still consider it unnecessarily obscure and hard to read. The mark of a > good programmer is that his code is *easy* to read, not just *possible* to > read. Using every obfuscatory feature of the language, perhaps in the > (oft-mistaken) belief that it improves efficiency, and then pleading that > "any experienced programmer should be able to understand that" is the mark > of someone who doesn't understand what this business is about. Henry, I have read a number of your postings about the "professionalism" of code readability, and while I generally applaud and agree with you, there is nevertheless a feeling I get whenever I read such an article that you apparently believe that that which is most easily readable by one programmer is also most easily read by another programmer. I heartily disagree with this notion (if it IS your notion). My most heavily-used language before learning C was PL/I, which looks much like C *structurally*, BUT without the side effects such as imbedded assignments that C has. Perhaps that is the reason I tend to agree with your statements somewhat. However, as I get more used to reading C of various flavors, such constructs HAVE gotten easier for me to read, and they may someday become easier for me than PL/I-style, if for no other reason than familiarity. I tend to target a programmer with a thorough knowledge of the language, but I try to refrain from forcing that programmer to exercise his powers of lexical analysis without warrant. I do NOT assume that that programmer has read a lot of AT&T code (a dubious distinction) or a lot of anybody else's code, as you seemed to in a posting not long ago on the topic of indentation style. I gathered then that your feeling was that anyone who deviates from K&R (and, I suppose, AT&T kernel default) style was being UNPROFESSIONAL by doing so REGARDLESS of how readable one judged this style to be to his targeted reading population. Obviously, I disagree with this, perhaps because I have programmed in C for years and have never done Unix kernel work. Without stating where I put my braces (I don't want to start any more religious wars), I will state that they differ from K&R style, and that they are positioned such that, in MY estimation, MOST human beings (not just kernel hackers) that read it can adapt to it based upon NO assumption of their C reading experience. And, yes, I suppose I recommend this to others. -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc