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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Xref: utzoo comp.software-eng:1133 comp.lang.ada:2045
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!serene!rfarris
From: rfarris@serene.UUCP (Rick Farris)
Newsgroups: comp.software-eng,comp.lang.ada
Subject: Re: comments on comments on comments
Message-ID: <426@serene.UUCP>
Date: 24 Feb 89 09:24:02 GMT
References: <419@serene.UUCP> <4534@hubcap.UUCP>
Reply-To: rfarris@serene.uu.net (Rick Farris)
Organization: Serenity BBS, Del Mar, California
List-Id: <comp.lang.ada>

In article <4534@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:

| I use a tactic which essentially makes comments as inherent a part of
| the code as possible: I make all package, procedure, function, type,
| and variable names as descriptive as reasonably possible.

[some examples deleted]

Yes, this is the only way I've seen documentation that tended to be
maintained with the code.  Personally, I'm a proponent of 4th
generation reverse engineering tools to do things like structure
charts, etc, since they are *never* maintained if it has to be done
manually. 


| Also, I've learned to type very quickly, through long hard experience.  :=)


As the ADAge goes, "Programs are *written* once, but *read* many times."


Rick Farris   RF Engineering  POB M  Del Mar, CA  92014   voice (619) 259-6793
rfarris@serene.cts.com     ...!uunet!serene!rfarris       serene.UUCP 259-7757