APS101: Rules for Assignment 3

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

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.


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!)

  1. Put only one public class in each .java file.

  2. Submit your .java files (the source code), not your .class files. Do NOT rename your .class file to make the electronic submission work.

  3. Don't ever use package statements, even if your favourite IDE inserts them automatically. Delete them if they appear.

  4. 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.


Style Rules

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

  1. Use Java style conventions for your method and variable names (start with a lowercase letter, then use lowercase except for the beginning of a new word within the name).

  2. Write a good comment for each class, each instance variable, each static variable, and each method.

    Use Javadoc comments, including @param and @return tags. Your method comments must mention what, if anything, the method returns, and the purpose of each parameter. The comment must be grammatically correct.

    The variable comments should be brief and just say what the variable is used for. They should also be clear and grammatically correct.

  3. 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.

  4. 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.

  5. Put a blank line before every comment that appears on a line by itself.

  6. 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;
                
  7. 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;
                
  8. Place opening brace on the same line as the method/class header. The first example below is good, but the second is not:

       
    	    public void blah() {
    	        ...
    	    }
    
    	    public void blah()
    	    {
    	      ...
    	    }
                
  9. 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)) {
    	      ...
    	    }
                
  10. 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);
                
  11. Similarly for assignments:
    	    if (a < b) {
    	      ack = false;
    	    } else {
    	      ack = true;
    	    }
                
    Replace it with code like this:
    	    ack = !(a < b);
                
  12. 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.

  13. 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