Code Quality Highlights

The Code Quality Guide is a very comprehensive guide to code quality in our course. However, it’s designed to work for the entire quarter which can make it challenging to read in the beginning since there are many concepts covered there that we have yet to discuss.

TAs will be grading your work each week to provide feedback on your code quality so that you can improve in future weeks. Sometimes you will receive a “-0” to indicate something was wrong, but it was not worth a deduction yet. Most things graded as a “-0” will eventually be a deduction in a future week. This page outlines some of the most important parts of the Code Quality guide to consider for each take-home assessment that will become non-zero deductions on that take-home assessment. This list is not meant to be exhaustive, but does highlight the most common issues.

We list the assignments in reverse order, as the points that relate to previous assignments will relate to all future assignments.

• Take-Home Assessment 7: 20 Questions
  • class design errors:
    • not using calls on this(...) to eliminate redundancy by having one constructor call another
  • data structure errors:
    • not using x=change(x) when appropriate to simplify code
    • poor choice of constructors for a node class (e.g., unused constructors or just a zero-argument constructor)
  • miscellaneous errors:
    • using \n unless to produce one line of output with printf
    • poor choice of constructor (e.g., setting fields immediately after construction when they could have been set by using a different constructor)
• Take-Home Assessments 6: Anagrams
  • No new code quality highlights
• Take-Home Assessment 5: Grammar
  • control structure errors:
    • structuring a recursive solution so that it has extra recursive cases or extra base cases that are not needed
    • looking ahead in a recursive method (i.e. structuring a solution that handles a base case preemptively rather than leaving it for a future recursive call)
  • method errors:
    • unnecessary parameters with redundant information that is available to the method from another source
• Take-Home Assessment 4: Evil Hangman
  • method errors:
    • not decomposing complex methods into logical subtasks that each have their own method
  • data structure errors:
    • excessive inefficiency when using collections (e.g., using a foreach loop to find a value of a map when a call on get would return the value)
    • using a collection inappropriately
  • miscellaneous errors:
    • Incorrect use of type (e.g., double instead of int, int instead of boolean, String instead of char for a value known to be exactly one character)
    • Computing a value multiple times when it could have been computed once and stored in a variable.
• Take-Home Assessment 3: AssassinManager
  • commenting errors:
    • method header does not describe the purpose of each parameter or does not describe the meaning of the return value of a non-void method
    • commenting on a specific client of the class (e.g. AssassinMain)
  • readability errors:
    • nondescriptive names for local variables or methods
  • control structure errors:
    • bad use of if/else (e.g., empty branch, if/if instead of if/else, unnecessary tests, etc.)
    • redundant code or unfactored conditional statements
    • bad use of loops (e.g., including an unnecessary check before a loop that repeats the loop test)
  • method errors:
    • not throwing exceptions at the top of a method when detecting the error does not require significant computation
    • using if/else instead of if for exception code (non-exception code should not be in an else branch)
    • modifying a parameter to a method when such modification was not part of the intended behavior
  • miscellaneous errors:
    • failure to simplify code (e.g., not factoring out common code, extra tests or loops that aren’t necessary)
• Take-Home Assessment 2: GuitarHero
  • commenting errors:
    • implementation details included in comments for a class or its public methods
  • readability errors:
    • lines over 100 characters
    • not following Java naming conventions (e.g., not using camel case, not using uppercase letters and word-separating underscores for constants)
    • one-letter or nondescriptive field names
  • method errors:
    • unused parameters
    • unnecessary returns
    • re-implementing methods (i.e., writing code for a commonly used method such as Arrays.toString)
  • class design errors:
    • incorrect constant declaration (e.g., not final, not static)
    • extra public methods or constructors not in the specification
    • not including either “public” or “private” for a method declaration
  • miscellaneous errors:
    • redundant code
    • unnecessarily inefficient code (e.g., constructing a new object on every iteration of a loop when it could have been constructed once before the loop)
    • not using interfaces when possible to refer to variables, parameters, fields, and return values
    • not using generic types properly (e.g., manipulating a Stack versus a Stack<Integer>)
• Take-Home Assessment 1: LetterInventory
  • commenting errors:
    • class header missing or doesn’t describe both student and program
    • method header missing or does not document pre and post-conditions
    • method header does not describe exceptions that are thrown when preconditions are violated, including the specific type of exception and the conditions under which it is thrown
    • method header does not document important behavior including subtle cases like an empty structure or a search value not found
    • blind copying of text from assignment writeup
  • readability errors:
    • bad indentation
    • some method or constructor does not have a blank line before it
  • control structure errors:
    • bad Boolean Zen
  • data structure errors:
    • extra data structures that aren’t necessary
    • bad usage of arrays (e.g., funky/incorrect indexing/usage)
  • class design errors:
    • extraneous data fields
    • initializing non-final data fields outside of a constructor
    • non-private data fields
  • miscellaneous errors:
    • using a specific numerical value when the value can be obtained in a more general way (e.g., even if an array called data is expected to be of length 100, code to manipulate it after construction should use data.length instead of 100)

Forbidden Features¶

In general, once a class has been discussed, it is available for use by students. For example, the String class and the Arrays class were covered in the CSE142 course, so it is reasonable to assume that you can use methods from those classes without asking permission. Student should realize, however, that saying that you are not forbidden from using a certain construct is not the same thing as saying that it is a good idea to use a certain construct. We don’t give advice to students about which constructs to use. You have to use your best judgement to decide and part of our assessment is assessing your design choices. In addition, there are some constructs that you are not allowed to use, as described in the next paragraph.

Java has grown to be a complex language with many features. We don’t have time to teach all of these features in CSE143. We have a general rule that students should not use “advanced” material that we have not covered in class. In addition, we have identified several Java features that we do not want students to use. It is not bad style to use these features, but we want to have a level playing field for all students. For any one of these features, we prefer that either everyone in the class knows about it and can use it or nobody is allowed to use it. The following features should not be used in CSE143 homework or exam solutions:

• break, continue, return from a void method
• try/catch, annotations
• the var keyword
• Java 8 features (e.g., lambdas, streams, method references)
• toArray, clone
• StringBuilder, StringBuffer, StringJoiner, StringTokenizer, and String methods toCharArray, join, matches, repeat
• Arrays.asList, Arrays.copyOf, Arrays.copyOfRange, Arrays.sort
• Collections.copy, Collections.sort
• package declarations
• System.console()

Many students find themselves wondering, “What is that feature you are describing?” If you don’t recognize it, then you’re unlikely to use it, so the best answer is, “Something that we have decided not to teach you in this class so that we will be able to focus on the really important concepts you need to learn.”