Re: Coding Standards

[bobduff@world.std.com (Robert A Duff)]

In article <31AABC53.1080@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> 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