Re: Coding Standards

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Robert A Duff wrote:
> 
> >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.  ;-)

I don't think you understand. The _core_ of my argument is that the code should
be as self-explanatory as practical, to enhance (a) readability, (b) 
maintainability, and (c) reusability. I accept that there are limits to this goal; 
for example, that knowledge of the Ada standard is still required. In addition, 
for certain kinds of maintenance (major changes in architecture, for example), 
knowledge of the system requirements, etc. are also necessary. However, I'm still 
looking for a case where knowledge of the coding standard used during development 
is legitimately critical to long-term maintenace of the software. Without such
a case, I don't see an obstacle to effective maintenance of code without
reference to the original coding standard.

> >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).  ;-)

If the way we use coding standards inhibits reuse, then maybe it's worth
looking at changing the way we write coding standards. Read on...

> 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!)

I still believe there is an alternative to requiring all projects to use a
common coding standard. That alternative is to write the coding standard in
such a way that it is not _required_ for maintenance. Again, the coding standard
should be designed to make the code self-explanatory. Without a coding standard,
there's no guarantee that this will happen. With a "good" coding standard, I think
the code can be read, maintained, and reused without knowledge of the standard.
This may sound paradoxical, but it makes sense to me.

An imperfect analogy: Suppose I reuse Ada 83 code on an Ada 95 project. I would 
hope that the coding standard for the Ada 83 code included provisions to avoid Ada 
95 incompatibilities. However, I should be able to maintain that Ada 83 code with 
my Ada 95 coding standard, without including a section on avoiding Ada 95 
incompatibilities.

Also, as I mentioned before, I think requiring knowledge of the coding standard to
understand the code has consequences beyond reuse. I think it also limits the
ability of the project to evolve the coding standard. Suppose, for example, the
project upgrades to an Ada 95 compiler. That project will probably want to upgrade 
their coding standard. However, if the coding standard has within it the meaning 
of certain non-obvious conventions, the project has to be very careful not to 
change anything in the standard that will invalidate those conventions. On the 
other hand, if the coding standard is not needed to understand the code, this 
should not be as serious a concern.

> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"