SVN instructions

Grading criteria

The 4 categories of grading criteria provided here apply to all labs and projects. For each lab or project we may use different grade point distributions in each category, but we will apply the same weights among these categories. This page will be updated as new labs and projects are introduced. Please check regularly for updates.

When the description provides a guideline on a certain subset of functionality earn up to X percentage of grade, code that satifies this subset will get a grade between (X-30)% and X %, inclusive on both ends. For example, if a submission for Project 2 provides correct implementation of Board and Square classes and nothing else, the grade will be between 40% and 70% of the total, inclusive on both ends. On the other hand, if your submission successfully implemented Board and Square classes, resetButton, user feedback at the end of the game, and the "Go back" button till the original board, your grade will be bewteen 100% and 130%.

Your code should perform the functionality specified in the description. The functionality must be implemented in a general way that your code can handle other inputs than the provided sample input case. Proper handling of invalid input is highly encouraged, if not required in the description.

• Hard coded input.
  Bad example:

  Scanner scan=new Scanner("mytest.txt");
  

  Get the file name from the user via keyboard or use program arguments. Being able to work with different files is better functionality.
• Some test cases produce incorrect output.
  For example, if your Histogram code prints a correct output for test but not for easytest (both are in Blackboard), then there will be point deduction.
• Some test cases crash your code.
  If your program crashes when given test cases that match the lab or project description, then there will be point deduction.
• Your code does not compile.
  

Your code should perform the described funcionality in an efficient way. For example, the following code is inefficient compared to the one below, as unnecessary if-else statements impose unnecesary condition checks. Even though two code blocks do the same functionality, the second code block will receive a better grade.

			if (index == 0) {
			    count[0] = count[0] + 1;
			} else if (index == 1) {
    			    count[1] = count[1] + 1;
			} else if (index == 2) {
			    count[2] = count[2] + 1;
			} else if (index == 3) {
			    count[3] = count[3] + 1;
			} else if (index == 4) {
			    count[4] = count[4] + 1;
			} else if (index == 5) {
			    count[5] = count[5] + 1;
			} else if (index == 6) {
			    count[6] = count[6] + 1;
			} else if (index == 7) {
			    count[7] = count[7] + 1;
			} else if (index == 8) {
			    count[8] = count[8] + 1;
			} else if (index == 9) {
			    count[9] = count[9] + 1;
			}

			count[index]+=1;

• Redundant code
  Code that is logically unnecessary as it can be combined into a simpler logic. Example of bad vs. good:

  a=a+b;
  a=a++;
  a=d;
  

  ... compared to ...

  a=d;
  

• Redundant functions:
  Functions where the transformation of input to output could be handled in a much simpler way. Example of bad vs. good:

  public int add(int a, int b){
  	return a+b;
  }
  

  ... compared to ...

  a+b;
  

Style of your code is very important in any professional environment. Proper style enhances readability, comprehensibility, and often quality of the code. Proper style includes following Java convention, formatting, comments, and sometimes method design.

• No or scarce comments
• Bad formatting:
  The rule of thumb in formatting is, the statements in the same logical block should have the same indentation. For example,

  if (index==0) {
      index++;
  max = count[index];
  }
  

  and

  if (index==0) 
      index++;
  max = count[index];
  

  are implementing different logic, and yet look very alike. Your code should not encourage confusing as the first code block does.
• Leaving debug code in output:
  Debug code, such as printing the count array before printing Histogram, is a great tool for you, but confuses the user who expects the Histogram. If you use debug code, either delete it before submission, or give an option to run your program without output from debug code.
• Leaving empty template in source code:
  The comment template provided by Eclipse is what generated Javadoc for your code. You can see that the code provided for Project 2 is used to generate the Javadoc, which now serves as requirement documentation for your software development. Providing empty template will result in poor documentation.
• Repeating a block of code vs. creating a method:
  Instead of copy and pasting a block of code it is much better to create a method that does the same job. This not only makes the code easier to read but also makes it easier to change and maintain. If there was any error in one block, you'd need to fix only once in the method, instead of fixing in every block. For example, in Project 1 instead of having the code for sending the email twice in your code, you can make a method that sends an email to given name and email address.
• Not following the programming language's naming convention:
  Following the convention improves the readibility. Java's naming convention states that Class names should be capitalized, method and variable names should be lowercase, and the file name should match the class name. Constant variables are all in uppercase.

Lab or project descriptions serve as requirements for your software development. Failing to meet the requirement will result in point deduction.

• Not matching Javadoc:
  Javadoc is a common way to communicate between programmers, and failing to match the Javadoc description will break the whole project. Even if your code provides functionality on its own, it will not work with other code that relies on Javadoc.
• Wrong SVN path:
  When the lab or project description specifies SVN path, you must use the provided path. Failing to meet this instruction delays grading feedback for everyone.
• Using String methods other than toCharArray in Palindrome in Lab 4.