For this Project 1 Index milestone, your project must maintain the functionality from the Project v1.1 Tests assignment, do an initial refactoring pass to that code, create a v1.2.x release, and undergo a single 1:1 code review with the instructor.

<aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" /> Usually, you do not request code review of the same version of code you used to earn your v1.1 test grade. You should refactor your code first based on the feedback you received in your Homework v1.2 Review and based on the guidelines below.

</aside>

TABLE OF CONTENTS


Prerequisites

You must complete the following assignments before beginning to work on this one:

Untitled

<aside> <img src="/icons/warning_gray.svg" alt="/icons/warning_gray.svg" width="40px" />

You are STRONGLY encouraged to make the changes from your Homework v1.2 Review milestone BEFORE requesting this code review, or you will likely receive the exact same comments and need extra code reviews to complete this project.

</aside>

Code Cleanup

Clean up your code before requesting a code review. This includes:

  1. Make sure the indentation is consistent (either using tabs -or- spaces, not both). Eclipse has a “Correct Indentation” feature that can be run every time you save a file.
  2. Make sure the formatting consistently follows a code style standard. Eclipse has a built-in formatter that can be run every time you save a file.
  3. Make sure all of the members and methods have informative Javadoc comments. Each parameter, return, and exception thrown should be described. See the lecture code, homework, and Java API for examples.
  4. Make sure all variable, method, and class names are informative and avoid abbreviations. Use the “Refactor » Rename” feature in Eclipse when renaming any identifier.
  5. Make sure exceptions are thrown or properly handled in the main method. Do not output stack traces.
  6. Make sure to remove any println statements used for debugging code. Only the main method should produce console output, and it should always be informative and user-friendly.
  7. Make sure all compile warnings have been appropriately addressed. Do not use the @SuppressWarnings annotation—fix the underlying issue instead.
  8. Remove any debugging comments that are no longer needed, including removing commented-out code.

The Configuring Eclipse guide shows how to automate several of these steps every time you save a file.

<aside> <img src="/icons/warning_gray.svg" alt="/icons/warning_gray.svg" width="40px" /> We expect that your code may have 1 or 2 minor cleanup issues before a code review. However, we will charge 1 or more tokens for a significant number of repeat issues, or if it is clear you did not attempt to cleanup your code before requesting a code review.

</aside>

Grading

Your initial goal should be on simplicity first, since simple code is easier to debug and maintain. This gives us a baseline to compare against, making sure that we are only adding additional complexity to the code base for well-motivated reasons.

You can achieve this by using existing functionality as much as possible (and approved). Specifically:

You will then receive advice during your code review appointment on where it makes sense to add additional complexity for the sake of generalization, reusability, encapsulation, or efficiency.

If your code is too complex, you may be asked to simplify the code base and resubmit the code review. This is true even if you have a design that might pass later code reviews, since we need the baseline first before making other design considerations.

Otherwise, as long as your code is not overly complex, you will earn a grade for these milestones by attending your code review appointment on-time.

Next Steps

The following assignments may be completed after this one is complete.

Untitled

Related Content