If we run out of time to review all of your code, you will have to follow the resubmission process before the remainder of your code will be reviewed. Please address small things before your code review so we can focus on more important matters. Make sure your code follows a style and naming convention, is well documented, and passes all tests locally and remotely.
Each project grade is split into two components: tests (functionality) and code review (design). This guide details the process for signing up for code review of your projects. See the other project guides guides for other details.
We will use one-on-one code reviews with the instructor to evaluate your project design. We will be looking for the following when reviewing your code:
- Your code should follow proper code style and naming conventions.
- Your code should have no warnings.
- Your code should be well-documented using Javadoc notation.
- Your code should be object-oriented.
- Your code should be encapsulated, generalized, and reusable.
- Your code should be memory-efficient and time-efficient within reason.
This list is not exhaustive, and exactly what we look for will vary by project.
The code review process is required for each project. Only request code review if all of the following are true:
Your latest project release is properly formatted and commented (every member and method must have Javadoc) and has no warnings.
Your latest project release passes the
reviewscript on the lab computers. Unlike the
projectscript, this script fails if you have warnings or missing Javadoc comments. You must pass the
reviewscript to be eligible for code review. The usage is the same:
/home/public/cs212/review GITHUB_USER v#.#.#
GITHUB_USERwith your Github username (not your USF/CS username), and
v#.#.#with your release number. The script will output which tests you passed or failed.
For example, running the command
review sjengle v1.0.0will fetch the
v1.0.0release from the
project-sjenglerepository, verify there are no warnings or Javadoc issues, and run the
You have already passed the code review for the previous projects. For example, you may not request code review for project 3 until completing code review for project 2 and may not request code review for project 2 until completing code review for project 1.
You are not already signed up for an upcoming code review appointment.
If all of the above is true, follow the steps below to request project code review.
Several issue templates have already been provided for you. Select the “Review Request” template to get started.
Change the issue title to “Review Request: Project
v#is the release you want reviewed. For example, name the issue “Review Request: Project v1.0.0” to request a code review for release v1.0.0 of Project 1.
FULL_NAMEin the issue body with your full name. For example, “Sophie Engle”. This should happen automatically if you modified your issue templates.
GITHUB_USERin the issue body with your Github username. For example, “sjengle”. This should happen automatically if you modified your issue templates.
RELEASEin the issue body with the previous release you created. (This helps us make sure you are numbering the releases correctly.) For example, “v1.0.0” or “N/A” if this is your first release.
Link to the pull request for your previous code review, or enter “N/A” if this is your first code review. See the Autolinked references and URLs guide for details on how to link to a pull request on Github.
Assign the issue to our TA Olivia (
oliviakumar). This should happen automatically if you are using the correct issue template.
Label the issue with the
reviewlabel. This should happen automatically if you are using the correct issue template.
Label the issue with the appropriate project label. For example, add the “project1” label for Project 1 code review.
Add the issue to the appropriate project milestone. The milestones should be either “project1”, “project2”, “project3”, and “project4”. You will have to create the milestone if this is your first issue for the project.
Verify you have followed all of the necessary steps in the “Verification” section. To check a box, change the text
[x]instead or click the checkbox after saving the issue. Do not create the issue unless you are able to check all of these boxes.
There is an example project code review request in the project template repository. If you make a mistake, please edit the issue. Do not delete the issue or close the issue and create a new one.
The results of each code review may be:
Pass: This means you passed code review and do not need to resubmit this project. You may now move on to the next project. Remember to incorporate all of the functionality and design of this project in your next project!
Warn: This means you passed code review and do not need to resubmit this project. You may move on to the next project, but there are some comments you must address in your next project submission to avoid deductions in your next review.
Resubmit: This means you did not passed code review and must resubmit this project. You must first address all of the review comments, re-verify you are passing the project functionality tests before resubmitting your project for code review.
No matter how many resubmissions it takes, you will receive a 100% when you pass code review unless one or more deductions are made. Deductions are only made if you do not take this process seriously and waste the time of the instructor or teacher assistants. Specifically, the project grade will be adjusted as follows:
Receive –10% deduction if code review is requested without addressing the comments from previous code reviews.
Receive –10% deduction if code review is requested for a release without passing the verification process first.
Receive –10% deduction if you are significantly late or completely miss a code review appointment more than once.
Otherwise, you may resubmit your project for code review as many times as it takes to perfect your code.