General assignment requirements.

Programming Assignments: Individual assignments are to be completed by you alone. You may not share solution code or experiment code with other students or other programmers. Review the class policy on improper collaboration from the class syllabus and how this applies to individual assignments.

About one third of the assignments may be done in pairs using a technique called pair programming (Read the paper on pair programming to understand how the technique works.). Turn in one solution  for the pair. (Submit the assignment to one partners turnin account.) Once you start working with a partner on an assignment you may not switch partners. If you do not wish to work with a partner after starting on an assignment you must both complete it individually. You must inform your TA(s) via email if you start working on an assignment with another person and decide to finish as individuals. You may not re-pair after starting the assignment with someone else. You jay start working on on your own and then working with another person. When working on pair programming assignments you are expected to spend at least 80% of your time on the assignment working with your partner, together at one computer, taking terms typing, and navigating.

Programs will be written in Java, using the Java 2 Platform Standard Edition 6.0. See the software page for information on downloading and installing Java at home.

Assignments are due by 11pm on the due date.,

You have 6 free late (slip) days in 1 day units (1 second  to 24 hours = 1 day) for the semester.

• You may divide your slip days across the assignments in any way you wish to extend deadlines for the assignments except you may not use more than 2 slip days on a single assignment for assignments 1 - 11. No slip days may be used on the last assignment, number 12.
• On pair programming assignments (See above for more information), both members of a pair use their own slip days, and both must have the required number of slip days. If both students do not have the required number of slip days it is a 0 for both students.
• You may not use slip days to turn an assignment back in for a re-grade.
• Weekends and vacation days do not stop the slip day clock. For example if an assignment is due on Thursday the last day you may turn it in is the Saturday just after the due date.
• To help the TA track your slip-day status you will complete the slip day portion of the appropriate comment in your source code file you turn in.

Unless prohibited by the assignment handout, you may use any component of the language or standard library (The Java API).

Assignments must compile and run with Eclipse in the Painter Microlab.

Assignments will either be submitted as a single Java file or  in the form of a single JAR (Java Archive) file. Each assignment will specify exactly what to turn in. Assignments that are not in the correct format or not named correctly will be penalized as described below.

Assignments must be turned in via the Microlab turnin program. If you are registered for more than one computer science class you must ensure that your turn your assignment in to the correct, CS314 directory. You must turn in a file with the correct name and in the proper format. (The source code if I ask for the .java file or the source code files packaged as a jar file if I ask for that. The format will be specified on the assignment page.)

If you do not follow the instructions and specifications for assignments (name, where to turn in, jar file format) you cause extra work for the graders and myself. As a student and potential software developer you must follow instructions and specifications. When you fail to follow instructions it causes you to become a special case. With over 300 students and a very short amount of time available to us, the TAs and undergrad proctors use scripts to streamline some aspects of grading. Failure to follow the assignment instructions and specifications causes these scripts to fail and the graders must spend more time on your submission. The following penalties are in place because there must be consequences for failure to follow instructions. Please read this account of a student who has seen the issue from both sides.

Penalties for failure to follow instructions and specifications on assignments:

• If a file is turned into the wrong account you must contact the instructor with the details. This will cost you 1 slip day. If you do not have 1 slip day the assignment grade is a 0.
• If a file is turned in with the wrong file name you must inform your TA. This will cost you 1 slip day. If you do not have 1 slip day the assignment grade is 0.
• If turning in a jar file you must turn in the source code. (The .java files, not the .class files.) If you only turn in the .class files your assignment grade will be 0.
• Classes must be in the default package (no package statement) unless otherwise specified. You will lose 4 points if you put a package statement in your program.
• An assignment that does not compile or does not run, loses all correctness points. Unless otherwise specified classes must be part of the default package. If not you will lose correctness points because you program will not compile.
• There may be multiple versions of your program on your computer. We will grade what you turn in. If you turn in the wrong file (for example the original shell provided by the instructor with no changes) your grade will suffer accordingly. Most likely a 0. (Time stamps from your system are proof of nothing. It is trivial to change the system time on computers.)
• You must add the header and fill it in for every file you turn in or you will 2 lose points.
• You may not use disallowed classes or methods. You will lose 2 points per occurrence.

Assignments grades are not scaled to effort or time spent working on them. (You may spend a large amount of time working on an assignment and still lose many points because your program is not correct.) The programs are not graded on a strictly linear scale. Points will be deducted for failed test cases, poor style, poor efficiency, lack of necessary comments, convoluted algorithms, lack of student provided test cases, lack of answers to questions regarding the assignment, and other reasons deemed appropriate by the instructor.

Each assignment will specify whether it must be done individually or as a pair.

Assignments will be checked for plagiarism and copying using Moss. You may discuss high level design issues with your fellow students, but sharing algorithms or code or obtaining solutions from another source constitutes academic dishonesty and will result in an F for the course. Review the class policy on cheating.

The teaching staff will grade, comment, return, and post the grade for an assignment within 6 days. A grade can only be disputed within the following 5 days. (This isn't a weekend bazaar. If there is an error in your grade you have one week to contact your grader. We won't go back at the end of the term to look at an assignment from early in the term.) You are responsible for contacting your TA or proctor if you assignment is not graded in a timely and accurate fashion.

All grade disputes must be made in writing by email to the grader with supporting evidence or arguments, and will result in the entire assignment being re-graded. Remember, no whining.
 

Testing:

• Testing your solutions is an important part of programming.
• I will provide some tests with each assignment, some of which may be in error.
• You will create additional test cases for it. Programs will be graded using additional test cases created by the teaching staff.
• I encourage you to use the Piazza discussion group to address which tests of mine are incorrect and to share tests you write.
• Tests may be posted to the class discussion group on Piazza. There is also a useful tool for posting code to retain formatting and syntax highlighting. It is called pastebin and the URL is http://pastebin.com/. Feel free to post your tests to that web page and provide the link via Piazza. Do not use pastebin or other websites to post any solution code.

Assignments will be checked for correctness with more tests generated by the instructional  staff. Your assignment may pass all the provided tests and still be incorrect. Grading test cases will not be published. If you would like to see the test specific test cases your code failed on you must meet with your TA during their office hours to see the test cases.

Design, Style, and Documentation

• Use if statements that throw exceptions to check for preconditions and post conditions on all public methods.
• Use methods and parameters to replace redundant / repeated code.
• Make instance variables within classes private.
• Do not use static data as a form of global variables.
• Break up long methods (over 20 lines of code) into smaller methods.
• Use consistent tabbing /spacing to make you code easier to understand and follow. There are some auto indentation features in eclipse, google it.
• Use a consistent brace style to make your code easier to understand and follow.
• Include white space to make your code easier to understand and follow
• Limit the scope of variables to the smallest reasonable scope possible
• Give sensible names to your classes, method names and variable names. Follow the Java naming conventions: http://www.oracle.com/technetwork/java/codeconventions-135099.html#367. Good advice also at this site: http://geosoft.no/development/javastyle.html#Naming%20Conventions
• Use descriptive variable names where appropriate. Consider the following example (from a style guide for a similar course at Stanford.)
  
  BAD VARIABLE NAMES:
  public String Spork(int x, String y) {
    int pizkwat = mumboJumbo(y);
    if (pizkwat < x)
        y = y.substring(0, pizkwat);
    else
        y = y.substring(0, maxChars);
    return y;
}

GOOD VARIABLE NAMES:
  public String void breakWordAtSpace(int maxChars, String toChop) {
    int firstSpace = findFirstSpaceInString(toChop);
    if (firstSpace < maxChars)
        toChop = toChop.substring(0, firstSpace);
    else
        toChop = toChop.substring(0, maxChars);
    return toChop;
}
 
• Comment every class and method
• For class comments, describe what the class does or any special properties of the class.
• For method comments this is the expected format /* <What the method does, preferably in one line> /* <Describe each input parameters/arguments of the method, also in one line> /* <Describe what the method returns>
• Comment your code inside methods as necessary. (Complicated algorithms or sections of code should be commented. What seems obvious to you will not be obvious to others. Comments should summarize what is going on, not restate the obvious.)
• Use assertions to check your logic in your code.
• Avoid use of the break and continue keywords. There are times these can be useful, but most beginning programmers misuse them. The use of break especially indicates you have spread the exit conditions for your loops like dust in the wind. Instead of placing them at the start of the loop.
• Don't use "raw types" for data structures with parameterized types. Example always specify ArrayList<Integer> list or appropriate type. Don't use ArrayList list.
• Initialize instance variables in constructors as necessary. (using default values is okay)

Efficiency: Worry about this last, but your program should run as fast as possible and use as little memory as possible within the constraints of the assignment.