Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watnot.UUCP
Path: utzoo!watmath!watnot!jjboritz
From: jjboritz@watnot.UUCP (Jim Boritz)
Newsgroups: net.singles,net.cse
Subject: Re: portable code
Message-ID: <11577@watnot.UUCP>
Date: Wed, 5-Mar-86 16:46:23 EST
Article-I.D.: watnot.11577
Posted: Wed Mar  5 16:46:23 1986
Date-Received: Fri, 7-Mar-86 03:44:25 EST
References: <653@moscom.UUCP> <569@hoptoad.uucp> <11569@watnot.UUCP> <1087@burl.UUCP>
Reply-To: jjboritz@watnot.UUCP (Jim Boritz)
Organization: U of Waterloo, Ontario
Lines: 59
Xref: watmath net.singles:10679 net.cse:673
Summary: 

In article <1087@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) 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.

I have seen alot of assembly language programs some were comment extremely
well and others extremely bad.  Most of the bad ones were the ones which
had a comment on every line.
A great many of the well commented programs had enough comments to make
code segments easy to understand, but they were far from the comment per
line guideline which you mentioned.  

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

One professor does not a department make, nor does one computer science course
make a good computer scientist. For every good Prof out there, there is also
a bad prof.

>
>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 was a tutor for an assembly language course a few months ago.  When a       
student does not know that part of their code is wrong, what is to prevent
them from putting this wrong piece of code in their programs.


>-- 
>
>The MAD Programmer -- 919-228-3313 (Cornet 291)
>alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
>			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj

Asides from all this marks cannot be assigned simply upon the appearance
of a program.  For one thing marks must be assigned consistently.  In 
order to assign marks consistently the marking process must become somewhat
mechanized.  This leaves you with a big problem when someone writes a 
bunch of crap for a program and then asks you to try to find the problem when 
it doesn't work.  After pouring over this persons spaghetti for twenty minutes
trying to wrap your mind around logic which has been reversed three times, 
all you find is a missing semi-colon.

At the end of it all you are still forced to give marks out for the parts 
that worked.

Jim Boritz