Expectations Around Homework

Late Policy

Barring an emergency or a pre-arranged extension (with Professor Fisler), late homework is not accepted. We begin running grading scripts moments after the homework deadline (yes, at 11pm). We will often go over interesting parts of assignments in the next class. Late assignments interfere with both activities.

If you have a late concern about or problem with your homework, submit whatever you have at the deadline, then contact Professor Fisler about it. This establishes what you had done at the deadline, which makes it easier to fairly address your issue.

Please don't submit homework by email unless you had a problem getting to InstructAssist. All of our grading workflow starts from the submission areas in InstructAssist.

Homework Partners

You are welcome to work with a partner on homework assignments, but you are not required to. You may select your own, or fill in the form that will be linked to each homework handout to have us pair you up. You are welcome to change partners from week to week (we encourage this, unless you have a productive relationship that helps you both learn the material.)

If you do work with a partner, we strongly recommend against you splitting the problems and each working on half. Each set of problems is designed to teach you a set of program patterns which could show up on exams or quizzes. If you only do half the problems, you only practice half the patterns. Especially if you are finding the material challenging, only do half the homework will ultimately work against you.

Separating Tests from Code

Our autograding software will look for tests in files that have either Examples or Test in the filename (such as Examples.java, DilloTests.java, Hwk1ExamplesGood.java). Tests that are left in any other files will not get detected (and hence not get graded). Similarly, the autograder will not look for classes or methods in these tests files, so non-test classes in these files will not get graded.

Please be sure to separate your code and your tests so that the grading software can find them. You will lose points for failing to set up your files as described here.

Your files can be organized into any subdirectories that you wish.

If you are having problems getting your code to compile before submitting, at least try to get the compilation errors out of your test files. Tests are much harder for us to grade by hand than code, and we have separate grading processes for each.

Directories and Packages for Your Code

The tutorials show you how to put your files in something called the default package (if you don't know what that is, don't worry about it--you won't run afoul of this without trying). All of your files must be in the default package for our grading software to find your work. If your file starts with a line like package ..., you are NOT using the default package.

Protecting Your Files

You are responsible for making sure your files are not accessible to other students. Failure to do so constitutes a violation of the course's academic integrity policy.

For Git users: If you like using github to manage your files, it is your responsibility to make sure that your files are not visible to other students (or the public). Either use bitbucket or get the github student pack to protect your work.

Formatting and Documentation Expectations

  • Put the names of all students for whom the assignment is submitted (when pairs are allowed) in at least one of your files.
  • Annotate every method get with a brief comment explaining what the method does. This is analogous to the 1101/2 purpose statement.
  • Provide examples of data for all classes you define. Put these in one of your testing files (such as in an Examples class).
  • Provide test cases for all of your methods. We will check that your tests are correct relative to the problem statement. We will also check that your tests are reasonably thorough, in checking the various cases of the methods and their inputs.
    An assignment will often indicate specific methods for which we will grade your test cases particularly closely. For these methods, we will check whether your test cases detect our own set of broken solutions (by having at least one of your tests fail on our broken solution). Our broken solutions will have mistakes in the logic of the computation, but will satisfy the input and output types required by the program.
  • Use appropriate techniques to reuse common code.
  • Use newlines and indentation to produce clean code (we actually read your code, we don't just run it). Producing clean code is one of the evaluation outcomes for the course.
  • Submit only your .java files, not your .class files.

You do NOT need to:

  • Comment individual lines within your code unless something subtle is going on.
  • Provide 1101/2-style templates, unless a question asks otherwise.
  • Include error checking (until we cover that after the midterm--assignments will indicate when error checking is expected).