Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site bunker.UUCP
Path: utzoo!linus!decvax!ittatc!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: net.singles,net.cse
Subject: Re: portable code
Message-ID: <1097@bunker.UUCP>
Date: Wed, 5-Mar-86 10:06:05 EST
Article-I.D.: bunker.1097
Posted: Wed Mar  5 10:06:05 1986
Date-Received: Sat, 8-Mar-86 07:42:19 EST
References: <653@moscom.UUCP> <569@hoptoad.uucp> <11569@watnot.UUCP> <1087@burl.UUCP>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, Trumbull Ct
Lines: 43
Xref: linus net.singles:9635 net.cse:625
Summary: 

In article <1087@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes:
>In article <11569@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes:
>>Very few CS courses provide marks for things like style.  Sure you will 
>>lose marks if your programs are not clear, but not for bad sytle.  
>
>I had a prof who had two guidelines, both of which I thought were very
>sound:
>
>a) Assembler programs *had* to have at least one line/phrase of comment
>per line of code.  The comment had better not say, "Load r2 with r1"
>or you were history -- they had to be functional.

But requiring one comment per line at times implies such non-informative
comments.  For example, with a Z80 it takes three instructions to determine
if a pointer is null (LD A,H; OR L; JP Z,label;) -- should each of these
instructions have a separate comment?  I think not.

>b) Other programs were graded with one rule-of-thumb:  if he had to ask
>   you how a piece of code worked or why it was there, your answer had
>   better convince him that you did something so revolutionary or so
>   brilliantly devious in that portion of the code that he just couldn't
>   fathom the very *idea*.  This did not happen often.

This is a very good rule, and should apply to assembler as well as
any other language.  When writing code, one should note that it will
be read more times than written; therefore ease of reading should be
more important than ease of writing.

(Pet peeve: Many people seem to think that assembly language is
inherently unreadable -- this is nonsense.  Good code can be
written in assembly, and bad code can be written in C.)

>The above not only taught people how to comment meaningfully, it also
>prevented them from putting things in their code that were incredibly
>ugly, non-functional, or downright wrong -- "I don't know what the following
>2 lines of code do, but the program won't work without them."

I cringe when I see comments like that, too; but in the case where
someone has inherited someone else's trashy code, putting a warning
like that in is better than nothing.  Eventually, it should be replaced
when (if) someone figures out why the code is there.

Gary Samuelson