Common CSC 430 Eyeball Problems🔗

• Don’t check the length of the list on every recursive call; this can make a linear procedure run in n^2 time.

• Organize your code in a top-down way, following the instructions given in the syllabus.

• I don’t like having a strict line limit, but past 120 characters, it just gets ridiculous. 80-100 is fine.

• Indent your file correctly. You can just highlight the whole thing and hit ’tab’. This may sound pedantic, but improperly indented code can be very misleading; it’s painful to spend 30 seconds trying to understand why something is the way it is only to realize that I misunderstood the meaning of the code because of the indentation.

• My comments in the code begin with

  ;;>

  , search for them.

• Don’t use Id or Varref to represent the names of functions or parameters in fundefs; the extra wrapping is just unneccessary, and sometimes can create more debugging work. Just use symbols instead.

• Don’t use a name like param for a list of parameters; use params, instead. Again, this is misleading and makes the code hard to read.

• The syllabus asks you to start with a comment indicating how far you got in the project. This is particularly important when it’s incomplete. This will help me to give you credit for the parts that you did.

• In assignment 2, it’s fine to write functions that are essentially just uses of map. In later assignments, though, you should figure out how to use map, or the list comprehension forms (e.g., for/list).

• The parser isn’t really the focus of assignments after the second. I would probably put the parser down below the rest of the interesting interp stuff.

• You can check for test case coverage locally by enabling test case coverage in the "Language Details..." panel of the Language|Choose Language ... menu.

• We don’t worry too much about running time in this class, but the wheels fall off when you go exponential. If you (for instance) evaluate the function position twice on every application, you can get programs that take time 2^n in the nesting depth of application calls. You need to watch out for that.

• You want to be really careful about using cast; If a cast fails at runtime, it’s a bug in your program. You should use cast only in situations where you’re certain that the cast will succeed, but the type system isn’t sophisticated enough to deduce it.