Aesthetics, FORTRASH, and C

[McQueen]

In article <880126220237.2020019d at M5.Sdsc.Edu> Steve Lamont
<lamonts at M5.Sdsc.EDU>
writes:
(about COMMON being considered harmful)
>Howcome?  I've been programming in FORTRAN for about 10 years, both writing
>my own code and maintaining others' and find it useful to know which program
>unit (subroutine or function) has the capability of diddling with what
>external variable and which program doesn't.  Are you saying that lumping
>all externals into one pool is *more* maintainable?  How so?  How else do
>you suggest?  I'm genuinely interested.  But, then, again, I happen to like
>implicit declarations, too...;-) <---- flamers... note smiley guy...

Actually, it's not COMMON itself that's bad, it's how it's used.  For years,
DoD projects that used FORTRAN were not allowed to pass subroutine arguments in
the call itself, but were required (contractually) to use COMMON.  Evidently
there was some time cost involved in passing the arguments in the call, at
least on some compilers/machines.  This led, on large projects, to a
proliferation of variables and COMMONs (usually, blank COMMON was prohibited
and only named COMMON could be used).  Naturally, every time somebody added a
new variable to be passed via COMMON, everybody didn't get the word to
recompile everything so that integration was always a nightmare.  (I can still
remember the chief programmer coming into the terminal room once or twice a day
and shouting, "Everybody recompile, we just changed COMMON!"  The result of
using external variables at all is called "data coupling" and generally
considered not to be a Good Thing (causes problems in maintenance later on) and
should be discouraged.  Note that I didn't say "prohibited" because the
designer often has to make tradeoffs.  It just shouldn't be done as a matter of
course.

Since you put the smiley in, I won't comment on implicit declarations.

Stan