CSSE 220 – Object-Oriented Software Development

Guidelines for how Programs will be Graded

General Instructions for the Grader

Unless instructed otherwise, grade programs based on:

For any points deducted, put a CONSIDER tag saying how many points deducted and why.

Each assignment will be accompanied by a rubric that will specify precisely how many points each of the above criterion is worth. Please see a quick description for each criterion below:

Correctness

For each item marked (per the grading instructions specific to the assignment):

Style

Given the assignment rubric, remove points for a violation of EACH of the following (up to the maximum allotted points for style):

  1. No duplicate or cut and pasted code
  2. Naming: Variable, method or class names are chosen poorly.
  3. Violation of Java Naming Convetions Classes should begin with a capital letter, fields and methods lowercase. Everything should be in camelCase
  4. Method Length: A method is too long (i.e., it should have been broken up into sub-method calls).
  5. Statement Length: A statement is too long (i.e., an intermediate variable should have been introduced).
  6. Improper Code Indentation: Control-Shift-F on the file causes any significant change. Deduct 10% of the points allotted for style for EACH such change.

    Eclipse highlights in purple the line numbers of lines that change when you do Control-Shift-F.

  7. Other Misc.: Any other poor style that you notice. (Let your instructor know what you take off per this “other poor style” bullet so that we can add it to the above list.)

Documentation

Given the assignment rubric, remove points for a violation of EACH of the following (up to the maximum allotted points for documentation):

  1. Missing Class Documentation: Class does not have a reasonable description header. At the beginning of each class, you must include a Javadoc comment which includes:
    1. A description of the class, which includes its main purpose/function
    2. How to instantiate and use the class
    3. One or more examples of how the class is used

  2. Undocumented (or poorly documented) methods whose name and parameter names do not make it clear what the method accomplishes.

    Such comments should rarely be necessary, since method and parameter names should generally be chosen to make the method self-documenting.

  3. Hard-to-read Undocumented Code: Chunks of code which are especially long and/or obtuse, yet lack an appropriate in-line comment. (Such comments should rarely be necessary, but such code shouldn’t be submitted.)

Examples

Remember: EVERY class must be documented! Above each class, you should include a (Javadoc) comment that has:

  1. A description of the class, which includes its main purpose/function
  2. How to instantiate and use the class

Here is an example that shows a simple class with “good” style and documentation. This represents the minimum documentation to receive full credit on any assignment when style/documentation is part of the grading rubric for the assignment:

	/**
	*	Class: GoodExample
	*	@author	John Doe
	*	Purpose: This class demonstrates the proper coding style.
	*		 It contains a method to double any integer value
	*
	*	Use:
	*		GoodExample firstExample = new GoodExample();
	*		int doubledValue = firstExample.doubleThatValue(5); //doubledValue should be 10
	*/
	public class GoodExample {
	
		// This class returns the value passed in doubled
		public int doubleThatValue(int incomingVariable) {
			return incomingVariable * 2;
		}
		
	}//end class GoodExample


Many of the “rules” outlined above are not just for the graders' benefit. All the above makes the code much more readable, hence MUCH more manageable. For example, consider the following method:

	public int a(int b, int c) {
		return (b < c) ? c : b;
	}
	
This code is very much not readable. Now consider the same method with better coding conventions:
	public int max(int num1, int num2) {
		int maxValue = num1;
		if(maxValue < num2) {
			maxValue = num2;
		}
		
		return maxValue;
	}
	


Method Length

For the size of methods, this can be tricky sometimes. Researching this topic on Google, you will find MANY opinions regarding the length of a method. Some say a method should NEVER be more than 15 to 20 lines of code. Others say that methods can manageably grow to 100 to 200 lines of code. For our purposes, methods should be kept short. The optimal size of a method allows the full method to be displayed on the computer screen WITHOUT having to scroll to see the whole method. This usually results in approximately 20 lines of code, but can be a little larger. Just remember two things: (1) One method, one task; (2) If you have to scroll to see the whole method, the method should be split.

Also, remember that a method should complete only one task. If you are attempting to do too much in one method, it can quickly grow to an unmanageable mess. In assuring that each method only completes one task, you also assure that the method size remains manageable.

For example, consider the following method to return a letter grade given an array of double values:

	public static char getLetterGrade(double[] grades) {
		double total = 0;
		for(double grade : grades) {
			total += grade;
		}
		double avg = total/grades.length;
		
		char gradeToReturn;
		if(avg >= 90.0)
			gradeToReturn = 'A';
		else if(avg >= 80.0)
			gradeToReturn = 'B';
		else
			gradeToReturn = 'F';
		
		return gradeToReturn;
	}

Even though this method is still quite small, it is apparent that more than this method contains more than just one task. The following better represents the proper coding style when splitting methods:

	//new method that just calculates an average from an array of doubles
	private static double getAvg(double[] grades) {
		double total = 0;
		for(double grade : grades) {
			total += grade;
		}
		return total/grades.length;
	}
	
	public static char getLetterGrade(double[] grades) {
		double avg = getAvg(grades);
		
		char gradeToReturn;
		if(avg >= 90.0)
			gradeToReturn = 'A';
		else if(avg >= 80.0)
			gradeToReturn = 'B';
		else
			gradeToReturn = 'F';
		
		return gradeToReturn;
	}