- Add Increments as branches:
Level-5
,A-CodeQuality
,A-AbstractClasses
,A-Packages
- Review some peer PRs counted for participation
1 Add Increments as branches: Level-5
, A-CodeQuality
, A-AbstractClasses
, A-Packages
- Do each increment as a Git branch. Here is an example:
- Start a branch named
branch-{increment ID}
(e.g.branch-Level-5
). You are recommended to have multiple commits in that branch. Follow the branch naming convention exactly or else our gradings scripts might miss your branch. - After the increment is ready, merge the
branch-Level-5
back on tomaster
, without a fast-forward so that git creates a separate commit for the merge.git tag
that merge commit asLevel-5
. - Push the branch to your fork so that the bot can detect it. As before, push the tag as well.
- Advanced git users: do not delete the branch after merging.
- Start a branch named
Level-5
: Handle Errors Level 5. Handle Errors
Teach Duke to deal with errors such as incorrect inputs entered by the user.
Example:
todo
____________________________________________________________
☹ OOPS!!! The description of a todo cannot be empty.
____________________________________________________________
blah
____________________________________________________________
☹ OOPS!!! I'm sorry, but I don't know what that means :-(
____________________________________________________________
When implementing this feature, you are also recommended to implement the following extension:
- Minimal: handle at least the two types of errors shown in the example above.
- Stretch goal: handle all possible errors in the current version. As you evolve Duke, continue to handle errors related to the new features added.
A-CodeQuality
: Improve Code Quality 2 Review some peer PRs counted for participation
Please wait till Mon, Aug 31st to start this task, to give others a few extra days to create the PR if they haven't done so yet.
This task is worth 2x2=4
participtaion points.
- Learn how you should review PRs in this task:
Textbook Git & GitHub → Reviewing PRs
The PR review stage is a dialog between the PR author and members of the repo that received the PR, in order to refine and eventually merge the PR.
Given below are some steps you can follow when reviewing a PR.
1. Locate the PR:
- Go to the GitHub page of the repo.
- Click on the Pull requests tab.
- Click on the PR you want to review.
2. Read the PR description. It might contain information relevant to reviewing the PR.
3. Click on the Files changed tab to see the diff view.
4. Add review comments:
- Hover over the line you want to comment on and click on the icon that appears on the left margin. That should create a text box for you to enter your comment.
To mark multiple lines, click-and-drag the icon. - Enter your comment.
This page @SE-EDU/guides has some best practices PR reviewers can follow. - After typing in the comment, click on the Start a review button (not the Add single comment button. This way, your comment is saved but not visible to others yet. It will be visible to others only when you have finished the entire review.
- Repeat the above steps to add more comments.
5. Submit the review:
- When there are no more comments to add, click on the Review changes button (on the top right of the diff page).
- Type in an overall comment about the PR, if any. e.g.,
Overall, I found your code easy to read for the most part except a few places
where the nesting was too deep. I noted a few minor coding standard violations
too. Some of the classes are getting quite long. Consider splitting into smaller
classes if that makes sense.LGTM
is often used in such overall comments, to indicateLooks good to merge
.
nit
is another such term, used to indicate minor flaws e.g.,LGTM, almost. Just a few nits to fix.
. - Choose
Approve
,Comment
, orRequest changes
option as appropriate and click on the Submit review button.
-
Step 1 Note these additional guidelines:
- Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.
- If the PR has received some review comments already, feel free to confirm/complement/question those comments in your review. Also, look for things the previous reviewers may have missed.
- At the end of the review, choose
Comment
(i.e., notApprove
orRequest changes
)
-
Step 2 Do the first PR review as follows.
- Comment on coding standard violations only.
- The review allocation is given in the panel below.
iP PR review allocation
Tutorial | Reviewer | First PR to review | Backup PR to review |
---|---|---|---|
TIC4001-F18 | JanuariusJang | ZhengShijieNUS | Chilaiping |
TIC4001-F18 | Yiheng0410 | pigoliver | Impala36 |
TIC4001-F18 | Chilaiping | dgc5213 | binbinhui |
TIC4001-F18 | e0260222 | daiweinus | adi-kd0021 |
TIC4001-F18 | Chenduo1412 | e0260222 | daiweinus |
TIC4001-F18 | skyventus | tototto | JanuariusJang |
TIC4001-F18 | Impala36 | e02161618 | Chenduo1412 |
TIC4001-F18 | daiweinus | adi-kd0021 | linqing42 |
TIC4001-F18 | dgc5213 | binbinhui | Yiheng0410 |
TIC4001-F18 | tototto | JanuariusJang | ZhengShijieNUS |
TIC4001-F18 | e02161618 | Chenduo1412 | e0260222 |
TIC4001-F18 | timmyly7 | skyventus | tototto |
TIC4001-F18 | adi-kd0021 | linqing42 | timmyly7 |
TIC4001-F18 | binbinhui | Yiheng0410 | pigoliver |
TIC4001-F18 | linqing42 | timmyly7 | skyventus |
TIC4001-F18 | ZhengShijieNUS | Chilaiping | dgc5213 |
TIC4001-F18 | pigoliver | Impala36 | e02161618 |
If the student you have been allocated to review has not created a PR (or the PR has a trivial amount of code), you can review the Backup PR to review provided in the allocation table. Failing both, pick a PR at random to review.
- Step 3 Do the second PR review as follows.
- Comment on other code quality guidelines (see the sections on Naming and Readability in this textbook chapter) you have learned so far. It's optional to comment on coding standard violations in this PR review.
- The review allocation is given in the panel below.
iP PR review allocation
Tutorial | Reviewer | Second PR to review | Backup PR to review |
---|---|---|---|
TIC4001-F18 | JanuariusJang | dgc5213 | binbinhui |
TIC4001-F18 | Yiheng0410 | e02161618 | Chenduo1412 |
TIC4001-F18 | Chilaiping | Yiheng0410 | pigoliver |
TIC4001-F18 | e0260222 | linqing42 | timmyly7 |
TIC4001-F18 | Chenduo1412 | adi-kd0021 | linqing42 |
TIC4001-F18 | skyventus | ZhengShijieNUS | Chilaiping |
TIC4001-F18 | Impala36 | e0260222 | daiweinus |
TIC4001-F18 | daiweinus | timmyly7 | skyventus |
TIC4001-F18 | dgc5213 | pigoliver | Impala36 |
TIC4001-F18 | tototto | Chilaiping | dgc5213 |
TIC4001-F18 | e02161618 | daiweinus | adi-kd0021 |
TIC4001-F18 | timmyly7 | JanuariusJang | ZhengShijieNUS |
TIC4001-F18 | adi-kd0021 | skyventus | tototto |
TIC4001-F18 | binbinhui | Impala36 | e02161618 |
TIC4001-F18 | linqing42 | tototto | JanuariusJang |
TIC4001-F18 | ZhengShijieNUS | binbinhui | Yiheng0410 |
TIC4001-F18 | pigoliver | Chenduo1412 | e0260222 |
If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.
- Step 4 [When you receive reviews for your own PR] Respond to comments received. You are recommended to (but not obliged to) respond to comments received from peers, especially if the PR reviewer asked you for more info. As mentioned in these guidelines, do not get into arguments with PR reviewers/authors.