From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7dd9b82cd363f55b X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Coding Standards Date: 1996/05/28 Message-ID: #1/1 X-Deja-AN: 157232824 references: <9605151401.AA04364@most> <31AABC53.1080@lmtas.lmco.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-05-28T00:00:00+00:00 List-Id: In article <31AABC53.1080@lmtas.lmco.com>, Ken Garlington wrote: >Funny you should mention this. We have a lot of non-programmers that read >(but do not modify) our Ada code. That probably explains our differences of opinion. I have never been in a situation where it was important for non-programmers to understand code -- if non-programmers need to understand something, I've always had to write it in plain English. In *my* experience, the only reason for somebody to understand code is because that person is a *programmer* who wants to modify it, debug it, interface to it, test it, etc. And, of all those, the most important is "modify", because that's where the most damage can be done by misunderstanding something. I certainly don't claim my experience is universal, of course. >... These folks include hardware engineers, >test engineers, etc. who need to understand a particular detail about >an algorithm. They rarely have to resort to an Ada manual to >understand a type definition. This is the wonderful thing about Ada: It's >fairly intuitive to read. Or at least, it should be. I gather you feel >differently. ... Well, it depends how far you go in that claim. Certainly Ada is more readable to non-programmers than some other languages, and I suppose that's mildly nice in *your* situation (though irrelevant in mine). However, if you grab a random person walking down the street, that person can understand a Robert Ludlum novel and today's newspaper, but certainly cannot understand a computer program, in Ada or anything else. But that's OK. I might not understand *that* person's job, either. >It also seems to me that your argument regarding the language manual is also >deficient, in that it assumes that if requring knowledge from one source is >necessary, that requiring knowledge from two sources is better. If that's the >case, why not use obscure sequences of letters for all declarations, with a >third document definining what these sequences actually mean? Generally, I >would think the _less_ complicated you make the process of understanding and >maintaining software, the better. OK, I call a truce in the effort to push each other's arguments to logical extremes. ;-) >This still begs the question I've asked on a couple of occasions: What >happens when your code is used on my project? If I reuse your code, am >I forced to use your coding standards, in order to keep the code maintainable? >This would seem to be a significant deterrent to its reuse. I thought that (repeated) question was rhetorical. My only answer is, "Yes, it's hard to interface project A to project B when the coding standards are incompatible." Maybe that's one of the (many?) reasons why Software Reuse hasn't really happened (at least, not to a great enough extent to solve all the world's software problems). ;-) Maybe if we all *agreed* on coding standards, software reuse would be easier. The industry is not mature enough for that, unfortunately. (We can't even all agree on a single programming language, not even within a single application area!) - Bob