Friday, February 2, 2007

Lessons from Lab3 grading

Lessons from Lab3 grading

Logistics
  • Do not forget to email all the code. Attach the files as attachments. When I grade your program, I download the files into an empty directory and do:
    javac *.java

    If, for any reason, there is an error in this step, it means that your program does not compile. This will be very bad for your grade. So it is your responsibility to verify everything. You must test your code before you submit. Once you have submitted, I suggest that you make a (temporary) empty directory, download the attachments into it, and test your program.

    This time I was more lenient. Some of you forgot to email the code or were missing some files. I only deducted 10 points and offered you a chance to resubmit.



  • To submit your lab, you should follow the instruction on this page:
    http://www.whizbangscholar.com/laboratory1.htm#General%20Instructions%20For%20Lab%20Reports
    In particular, you must "put your name and the Lab number (e. g. Lab 1) on the subject line." Otherwise, your submission may not be found.
  • AlienApp should contain the main method. Otherwise, it will be hard for me to look for your main class. (-5 if AlienApp is not found.)
    [update (2/5)]: Upon the second thought, I think this is unfair since the instruction on the lab sheet did not clearly specify which class should contain the main method. So I gave the 5 points back. If I miss anybody, please visit my office hours.
  • Do not forget to include the code listing of all classes.

Neatness
  • Bad handwriting is bad for your grade.
  • Some of you are confused between UML Diagram (showing containment) and class hierarchy diagram (showing inheritance). Please look into the book. Also, if we ask you to write 2 or more diagrams, please clearly label both of them.
  • Please use a fixed-width font for code listing. (Courier New is a good choice.) Please also make sure the font size is big enough, but not too big so that the lines get truncated or wrapped around. Do not print-screen the code. The quality is usually poor. Instead, print it out as text.
  • Color printing not necessary.

Coding Styles
  • Please make everything private unless it really needs to be public. If a subclass needs to read a variable, make it protected.
  • Please limit the lines' lengths to 80 chars (for nice printing and preventing truncation).
  • Limit the use of // comment, especially when it makes the line too long. Consider putting comments in another line. Use this style of /* comment */ instead for multi-line comment.
  • Indentation is important for the readability of your program. You can follow Prof Carlin's style or the book's style. Just pick one and be consistent.
  • One class per file: each class should be put in its own file.

Hall of Fame:
  • Very nice diagrams: Alvin Yip, Drew Martin, Christian Banzon
  • Francois Hebert: an army of 13 aliens
  • Steven Pease: 6 aliens with very amazing animation and interactions.

No comments:

Contributors