For this Project 3 Threads milestone, your project must maintain the functionality from the Project v3.1 Tests assignment, do an initial refactoring pass to that code, create a v3.2.x release that is 1.1x times faster than single-threading, and undergo a single 1:1 code review with the instructor.

TABLE OF CONTENTS

Prerequisites

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

Untitled

Code Cleanup

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

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.
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.
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.
Make sure all variable, method, and class names are informative and avoid abbreviations. Use the “Refactor » Rename” feature in Eclipse when renaming any identifier.
Make sure exceptions are thrown or properly handled in the main method. Do not output stack traces.
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.
Make sure all compile warnings have been appropriately addressed. Do not use the @SuppressWarnings annotation—fix the underlying issue instead.
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:

Use core Java classes and methods when possible. For example, do not write a sorting algorithm when it is possible to call Collections.sort instead).
Use homework classes and methods when possible. For example, use ArgumentParser for handling command-line arguments instead of creating custom code for the project.
Use existing classes and methods when possible. For example, if you already have a relevant class created from a previous milestone, consider modifying or adding to that code.
Do not use unauthorized third-party libraries or Java packages. For example, do not add an unapproved JSON writing library to your project or use classes within the java.util.concurrent package.

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.

Getting Started

Even though you do not need to implement new functionality for this assignment, you should clean up your code to maximize your code review appointment. See the Project Review guide for details.

Next Steps