root@hobbes.UUCP (John Plocher) (08/21/87)
Roy Smith writes: > My experience has been that most assembler code has one comment > per statement, often not very useful at that. In one of the asm language courses I took the instructor wanted a comment on every line (and a chicken on every plate :-) I couldn't see the reasoning behind such an arbitrary requirement until another student came to me with a problem in his code. As he spread out the 10 pages of PDP-11 asm source I noticed there were NO comments :-( When I asked why, he responded with the answer "The teacher said that comments tell what the program does, and I don't know what the heck it's doing!" :-) After that I noticed that the students were divided into two camps, those who commented after the fact: (the program works and I have 45 minutes before it is due; I might as well comment it...) add a, b ; add a to b and those of us who took the time to present the algorithm in a HLL: ; loop through the array and zero out each element ; mov r1, 1 ; for r1 = 1 to 10 step 1 do .l100 cmp r1, 10 ; bgt .l101 ; begin mov array(r1),0 ; array[0] := 0; inc r1 ; bra .l100 ; end; .l101 With this hindsight (there, Phil, I spelled it right!) it is easy to see that the comment on every line was required in an effort to force the students to determine WHY each line was needed, as well as making life easier on the graders. BTW, it was obvious by the grades given who followed each of the two commenting styles above. It seems to me that a good grading scale would be: does it work as required? 40% (minimal conformance) testing suite: 20% (extra credit for enhancements) commenting style: 20% (can grader/teacher follow algorithm?) algorithm quality: 20% (bubble sort vs quicksort...) The point being that a not so bright student who bashes thru and by brute force gets the assignment done to the satisfaction of the minimum assignment guidelines (comment on every line, implements the assignment to the letter, no more, no less,...) should NOT automaticly get a great grade. As you can tell, I consider an assignment to be the minimal specs on a program - it will do this and this by this time or it won't be elegable for full credit. The student should consider this to be the basis for their program and expand on the thing as desired - developing a table driven scanner instead of a gigantic case statement, adding data caches to a database design, using traps and interrupts instead of busy waiting for events... In effect showing not only an understanding of the algorithm being presented in the assignment, but enough of a mastery of it to expand on it. [ This is obviously not suited for a first time computer user, but by the third or fourth program these ideas should be presented. ] -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU