CS212: Comments after Problem Set 3

CS212 Grades
Comments after Problem Set 3

Doing the Problem Set

Some people should start earlier. Thinking about what you're doing is imperative. Many of the functions we saw we're over bloated and could have been written much more elegantly. HINT: Think before you hack.

Submitting the Problem Set

What don't you understand about a 72 character per line limit?
Of all 55 submissions, only 16.4% adhered to the 72 character limit. We know who these people are and we like them. Only 29.1% adhered to an 80 character limit (this includes the 72 character people). While 80 is okay, 72 is better and more likely to make us happy (which is a good thing). For the remaining 70.9% who went over 80 characters, please find the return key on your keyboard and use it more often. Thanks!
If this were a contest (which it's not) here are the winning numbers:

Line Lengths Problem Set Lengths

Bronze 161 characters 8 pages

Silver 254 characters 8.5 pages

Gold 481 characters 39 pages

Commenting

Your code is not holy, don't comment it like it is. Scheme is a self-commenting language, it only needs a little assistance from you. Consider the following:
(if (empty? l)        ;if the list is empty
    l                 ;return it
    (+ (head l)       ;otherwise, return the sum of the head of the
       (sum (tail l)));list and the result of the recursive call
The commenting here is completely worthless. It doesn't tell me anything I can't already figure out. There is a tendency to comment each part of a cond or case statement - again this is probably unnecessary. Another thing, you shouldn't really need to put comments in the middle of a function, unless it is really helpful.

RECOMMENDATION: Get the commenting under control before we refuse to grade your problem because we can't find your code.

Style

HINT: If you follow good style, you can keep your line lengths really short.

Don't let, let*, or letrec values unless you there's a good reason to. There are only two good reasons - it's a big computation that is needed more than once in your function. Second, it dramatically improves the readability of your code.

Also, putting in useless code is a really bad thing. We've been somewhat nice recently, but from now on, we will penalize heavily for putting in useless code. For instance:

(if (predicate? x) #f #t)
is better written as
(not (predicate? x))

(append (list 'implies) (list 'x) (list 'y))
is better written as
(list 'implies x y)

Eli posted some good examples of style to the newsgroup, but it's worth repeating here:
BAD: not clear that if has two parts.
  (if x y
      z)
  (if x    
      y z)
GOOD:
  (if x
    y
    z)
and this is also ok:
  (if x
      y
      z)

BAD:
  (something...)    ; a very long comment
GOOD:
  ;; a very long
  ;; comment
  (something...)

BAD:
  (let ; comment
       ((...))
    something)
GOOD:
  (let ((...)) ; comment
    something)
and if it's 
a long comment:
  ;; comment
  (let ((...))
    something)

BAD:
  (letrec ((x 1) (y 2))
    ...)
  (let* ((x 1) (y 2))
    ...)
GOOD:
  (let ((x 1) (y 2))
    ...)
-- Use let* only when needed, there's no
point in using letrec except for [mutual] 
recursive functions.

BAD:
  (cons 1 ())
BETTER:
  (cons 1 '())
BETTER:
  (cons 1 empty)
BEST:
  (list 1)

BAD:
  (if x y (if z u v))
  (if x (if z u v) y)
GOOD:
  (cond (x y) (z u) (else v))
  (cond ((not x) y) (z u) (else v))

BAD:
  (if x #t #f)
  (if x #f #t)
GOOD:
  x
  (not x)

The following examples can be 
considered as optional reading...

NOT-SO-NICE:
  (if (p? x) #t y)
  (if (p? x) y #f)
BETTER:
  (or (p? x) y)
  (and (p? x) y)

NOT-SO-NICE:
  (if (p? x) #f y)
  (if (p? x) y #t)
BETTER:
  (and (not (p? x)) y)
  (or (not (p? x)) y)

Abstraction

If you violate abstraction, you won't do well in this course or any other programming assignment you get (for another course or at a job).

Extending the abstraction is really a touchy issue. We won't be very concerned if you do this and get everything else right. However, if you extend something and nothing else works, you won't be very happy when you get your problem set back.

Written Assignments

So, when we say short informal proof, we mean both short and informal. Nevertheless, it is a proof, and in order to prove something you have to demonstrate some knowledge of the way things are evaluated (i.e. substitution model). When you have a written assignment that asks you to explain or prove something, you cannot simply describe what your code does -- this we can figure out by looking at your code.

Allowed Functions

Using functions and special forms that you haven't learned in class is generally a bad idea. Take a look at the Scheme/Swindle Quick Reference for a summary of things you are allowed to use. Be cautious though not to use anything that is only helpful for side-effects. Things like begin, when, and set! will get points off if you don't need to use it. You shouldn't have used eval anywhere -- we didn't teach it to you, nor does it appear in the Quick Reference.

	Line Lengths	Problem Set Lengths
Bronze	161 characters	8 pages
Silver	254 characters	8.5 pages
Gold	481 characters	39 pages