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:
For each item marked (per the grading instructions specific to the assignment):
Students should use:
Grader: You need not “grade” the students’ use of process (since it is hard to do so), but we reserve the right to reduce a student’s score if he/she is not using the above process.
Given the assignment rubric, remove points for a violation of EACH of the following (up to the maximum allotted points for style):
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.
Grader, you can put a single CONSIDER that says something like “-30% for 3 errors exposed by Control-Shift-F” – you don’t have to explain any further, since the student can do Control-Shift-F herself to see the changes.
Compiler Warnings: Any serious warning messages are left (students should use @SuppressWarnings if the source of the warning is intentional).
Note any missing documentation described below will generate a warning message. Deduct as a style or documentation error (but not as both).
Extraneous Variables: A variable is introduced where the code is much clearer without it. For example:
int answer = … blah …; return answer;
is clearer when written simply as:
return … blah …;
Variable Scope: A variable has greater scope than necessary.
For example: a variable that could be local to a method is instead a field, or a for loop variable is not local to the for loop.
Given the assignment rubric, remove points for a violation of EACH of the following (up to the maximum allotted points for documentation):
Undocumented (or poorly documented) private 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.
The following demonstrate the principles described above. See Java Coding Standards for a summary of the expected coding style and documentation. Remember: EVERY class must be documented! Above each class, you should include a (Javadoc) comment that has:
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;
}
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;
}