CSC 108H/A08H: Rules for assignments

In this course, you will be submitting most of your assignments electronically. We will be printing them for the TAs to mark, and we will also do a lot of automatic testing. Read and follow the following rules carefully.

We apologize for having to be so strict, but remarking takes a huge amount of time per assignment -- and with so many students, it becomes intractable.

You can use an automated style checker to help identify style transgressions. Information about the checker can be found here .

The most important rules

If you violate any of the following rules then you may get a zero on some or all parts of the assignment, WITH NO APPEAL ALLOWED. (Please notice that you have to go out of your way to violate them!)

Put only one public class in each .java file.
Submit your .java files (the source code), not your .class files. Do NOT rename your .class file to make the electronic submission work.
Don't ever use package statements, even if your favourite IDE inserts them automatically. Delete them if they appear.
Capitalization matters in Java, including in filenames. This means that class names must match the filenames exactly. For example, if your class is called AssignmentZero, your file must be called AssignmentZero.java, and not assignmentzero.java or Assignmentzero.java. Use the capitalization asked for in the handout and starter code.
Sometimes we will ask you to submit written answers to questions. Any submissions must be plain text only. You can easily ensure this by typing your answers in DrJava: these files MUST NOT be in Microsoft Word format, because Microsoft doesn't make a Unix version of Word. Using Notepad is OK.)
When an assignment specifies output, the output of your code must follow the specification precisely. This includes using exactly the capitalization, number of spaces, punctuation and line breaks specified. And you must not add anything extra to the output. Your program may be marked automatically (by another program!) and any output which isn't exactly as specified will receive a zero.

Style rules

If you violate any of the following rules you will lose substantial style marks.

Write a good Javadoc comment for each class, each instance variable, each static variable, and each method. In your method comments, include @param and @return tags when appropriate. <-- Write an informative comment for each class, instance variable, static variable, and method. Make sure that your method comments mention parameters and return type/values.--> Use proper English grammar and spelling.
Each line must be less than 80 characters long including tabs and spaces. Beware of "soft returns" -- some word processors, like WordPad, wrap lines automatically. If you use such a program, make sure that you press the return key yourself.

DrJava tells you what column you're in. Look in the lower-right corner.
Never compare a boolean expression to true or false. For example, if you find yourself writing code like this:
```
  if (a.equals(b) == false) {
    ...
  }
            
```
replace it with code like this:
```
  if (!a.equals(b)) {
    ...
  }
            
```

If you find yourself writing code like this:

  if (a < b) {
    return false;
  } else {
    return true;
  }

Replace it with code like this:

  return !(a < b);

Similarly for assignments:

  if (a < b) {
    ack = false;
  } else {
    ack = true;
  }

Replace it with code like this:

  ack = !(a < b);

Don't use return from the middle of loops, and avoid break and continue if at all possible. Why? Because if you use these your code is harder to read and understand: there should only be one way to exit a loop.
Use a tab width of 2 (DrJava's default), if you use tabs at all. The best way to make sure your program will be formatted correctly is never to mix spaces and tabs -- use only tabs, or only spaces. If you use a tab width of less than 2, it is your responsibility to make sure that your lines are shorter than 80 characters when we print your program. DrJava is set up at school to use a tab width of 2, and you can do that at home, too, in almost all IDEs.
Put a blank line before every comment that appear on a line by itself.
Put a blank space before and after every operator. For example, the first line below is good but the second line is not:
```
          boolean b = 3 > x && 4 - 5 < 32;
          boolean b = 3>x && 4-5<32;
            
```

When breaking up a long line break it before an operator, not after. The first example below is good but the second is not:

          boolean b = "Hello".charAt(3) + 3 > x
            && Integer.parseInt(s) < 32;

          boolean b = "Hello".charAt(3) + 3 > x &&
            Integer.parseInt(s) < 32;

Always use braces on if, else, and loop blocks. The first example below is good but the second is not:

          if (x > 5) {
            while (i > 3) {
      // Do something
    }
    } else {
    // Do something else
    }
    
    
    if (x > 5)
    while (i > 3)
    // Do something
    else
    // Do something else

Some tips on how the system works

If you resubmit a file, that is the only copy we will have. Your old submission will be overwritten, including the timestamp.
It's okay to submit extra files. We will ignore all files that we didn't ask for.
There may be marks given for a program that compiles, but does not produce correct results. Thus, it is always in your best interest to turn in something that compiles.
It is possible that these rules will be overridden for particular assignments. Any such changes will be announced in class or on the web site.