Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!glenn@LL-XN.ARPA
From: glenn@LL-XN.ARPA (Glenn Adams)
Newsgroups: net.unix-wizards
Subject: Re:  code quality
Message-ID: <2012@brl-tgr.ARPA>
Date: Wed, 9-Oct-85 11:00:47 EDT
Article-I.D.: brl-tgr.2012
Posted: Wed Oct  9 11:00:47 1985
Date-Received: Sat, 12-Oct-85 14:23:05 EDT
Sender: news@brl-tgr.ARPA
Lines: 21


With all this talk of "good" and "bad" code, I am wondering what value system
is being employed in articulating these terms.  I would imagine, without
digressing into a metasoftware diatribe, that they mean different things to
different people.  In particular, those who serve to achieve results, i.e.,
managers who more often than not emphasize short-term goals, probably don't
care what the code "looks" like as long as it "works".  On the other hand,
we programmers who have to "look" at the code, often for long hours seemingly
without end, tend to develop a set of values based on our own personal
aesthetics.  It is on this aesthetic level that code is often judged fish
or fowl.  But, one may argue that code really doesn't "work" when it "looks"
bad.  This often comes into play when someone, usually not the original
author, must "look" at such code, and "fix" it.  Usually, the "fix" involves
serious mastication resulting in a different "look" found to be more pleasing
to the person performing the "fix".  Occasionally, the transformed code which
now "looks" good, at least to the most recent author, is made to "work".
This usually holds true until the next "fix" must take place, at which time
the next author in line displays moral disgust at how that code could "work"
and "look" so bad...

Glenn Adams