Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!sri-unix!hplabs!tektronix!decvax!savax!elrond!adb
From: adb@elrond.UUCP
Newsgroups: comp.edu
Subject: Re: portable code
Message-ID: <455@elrond.UUCP>
Date: Mon, 10-Nov-86 17:26:41 EST
Article-I.D.: elrond.455
Posted: Mon Nov 10 17:26:41 1986
Date-Received: Wed, 12-Nov-86 02:14:34 EST
References: <653@moscom.UUCP> <569@hoptoad.uucp> <11569@watnot.UUCP> <1087@burl.UUCP> <11577@watnot.UUCP>
Reply-To: adb@elrond.UUCP (Alan David Brunelle)
Organization: Calcomp Display Products Division, Hudson, NH, USA
Lines: 57
Keywords: CS grading, style
Summary: A former grader joins in

In article <11577@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes:
>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.  
>>
>>
>>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.
>
>
> ...
>
>At the end of it all you are still forced to give marks out for the parts 
>that worked.
>
>Jim Boritz
> 


A couple of years back I TA'd some courses at U of New Hampshire, 
in which I tended to find that there were definately 3 types of 
programs submitted: those that didn't work, those that worked 
but weren't 'correct' in some manner, and those that were 'correct'. 
The first type is obvious, the second describes those programs that 
ran correctly against any input, but were not coded using the 
guidelines set forth (no goto's, well commented, using the proper methods being taught & etc.). The latter type (believe me) were few and far between. 
My biggest headache in grading the middle group was in trying to 
fairly place them in the propper position with respect to the other 
programs submitted. 

Let me explain, say program #1 ran well against the test suite, 
but used poor variable names, few comments and the like - but it was quite 
in line with the purpose of the exercise; meanwhile a second program (#2) 
was submitted, that also ran well, was much better commented but it 
did not accomplish the purpose of the exercise: eg. it did not use an 
array of records, but a group of arrays of different types.  How do you 
place the programs relative to each other? Did you side with #1 
because it better fit the assignment goal? Or with #2 as it was 
clearly better styled? 

I guess the question comes down to: Were we trying to reward students for
better programming 'style' or for learning the concepts of the course
at hand?

Alan D. Brunelle

uucp:	 ...decvax!elrond!adb		| "To do all the talking and not
phone:	 (603) 885-8145			|  to be willing to hear anything
us mail: Calcomp/Sanders DPD 		|  is greediness"
         (PTP2-2D01)			|	Democritus
	 Hudson NH 	03051-0908	|