Homework Regulations, Guidelines, and Expectations

Introduction to Computer Science

Collaboration

While you are encouraged to talk with other students about the homework you must not copy or share code. Do not show your code to others and do not look at other students' code. You should also not copy code from the web or anywhere else. If you submit an assignment with code that is not your own, you will fail that assignment. If you do this more than once, you will fail the course.

In general, it is fine to talk with others about any aspect of the assignments. But you should not share code or pseudocode under unless I have explicitly said that it is ok to do so. If you get help, advice, inspiration from someone in the class or from some other source you must acknowledge that source. Do so directly in your source code. Indicate what sort of help you got. If the source is a book or a website, include enough information so that someone reading your code can get access to it.

Style

In life, opinions tend to differ about what constitutes good style. This is true in programming, but to a much lesser degree. There are a number of style conventions that are almost universal (and for good reason), and you should use them in all your programs. I will not enforce a particular style in this class. However, it is very, very important that you develop a consistent style.

For this class I will use and evaluate your programs based on the coding standards written up for the into computer science sequence at the University of California, Riverside. Our textbook also has excellent style advice.

Evaluation Rubric

I will evaluate your programs using the following as a guideline.

1. Excellent: Program compiles without errors. Runs without errors and gives correct output. The output is formatted so as to be easy to read. Meets all specifications. Is clearly and thoroughly comments and is easy to read by someone who does not know in advance what the program is supposed to do. The program is not overly long and it runs efficiently. Where appropriate, the program is written in such a way so as to be (re)usable in other programs.
2. Good: Program compiles with few errors. Runs without errors and gives generally correct output, although may contain a few logical errors, especially concerning special cases. Meets almost all specifications. Output is fairly easy to read. Contains thorough comments and the program is generally easy to understand.
3. Fair: Program compiles with some errors. Program runs but contains logical errors and/or minor run-time errors. Program is poorly commented and is difficult to understand. Meets only some program specifications.
4. Unacceptable: Program does not compile or it compiles but contains run-time errors that render it useless. Contains no or few comments. Is difficult to understand.