Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!mangoe
From: mangoe@umcp-cs.UUCP (Charley Wingate)
Newsgroups: net.cse
Subject: Teaching (and Grading on) Style
Message-ID: <148@umcp-cs.UUCP>
Date: Fri, 7-Mar-86 20:22:16 EST
Article-I.D.: umcp-cs.148
Posted: Fri Mar  7 20:22:16 1986
Date-Received: Sun, 9-Mar-86 09:26:42 EST
References: <11577@watnot.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 28

In article <11577@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes:

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

Au contraire.  When I graded programs in the elementary courses, I gave out
only 50% of the points on functionality.  Everything else was on style.  You
had to have meaningful comments, you had to format the code in a certain
way, and you had to make the stuff generally legible.  I also took points
off for incredibly convoluted code; here at UMCP we want people to write
elegant and easily comprehensible code first, then worry about squeezing
every last bit of performance out of it.  (My definition of incredibly
convoluted code was anything I couldn't follow; there's no excuse for
someone in a freshman level course writing code that a reasonably
intelligent grad student can't follow.)

In my opinion, you can't hammer enough on style.

C. Wingate