For this Project 3 Threads milestone, your project must maintain the functionality from the Project v3.1 Tests assignment, address changes from the Project v3.2 Review assignment, create a v3.3.x release that is ideally 1.5x times faster than single-threading, and undergo a single synchronous 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 goal with your followup review is demonstrate how you addressed the TODO comments from the initial code review.

Address each TODO comment where it appears in your code base.
- If you are uncertain what the TODO comment means, reach out to the reviewer on Piazza with a link directly to the comment in your code.
- If you are uncertain if you are addressing the TODO comment correctly, try your best and request another code review when you are ready. Remember, you will still make mistakes throughout this learning process! You will get feedback in your next review, not in-between reviews.
Address issues related to each TODO comment everywhere they appear in your code base, not just where the TODO comment appears.
- The reviewer will only comment on the issue once; it is up to you to review your code for similar issues elsewhere and address them. You do not want to lose time in future code reviews for similar issues.
- Consider TODO comments from previous project milestones as well. For example, if you are advised to create a new class for Project 2 Search, consider what you learned about encapsulation from your Project 1 Index code reviews.

You will receive additional advice on the design of your code during your appointment, with an emphasis on generalization, reusability, encapsulation, and efficiency.

If you have too many unresolved TODO comments, you may be asked to resubmit the code review.

Otherwise, as long as you attempted to address the TODO comments from the previous review, you will earn a grade for these milestones by attending your code review appointment on-time. This is true even if you made a mistake in how you addressed a TODO comment!

Next Steps

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

Untitled

Prerequisites

Code Cleanup

Grading

Next Steps

Related Content