[CS2103-F11-4] NUScheduler #68
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #68 +/- ##
============================================
+ Coverage 72.15% 75.01% +2.85%
- Complexity 399 540 +141
============================================
Files 70 87 +17
Lines 1232 1737 +505
Branches 125 186 +61
============================================
+ Hits 889 1303 +414
- Misses 311 377 +66
- Partials 32 57 +25
Continue to review full report at Codecov.
|
aditi2313
added a commit
to aditi2313/tp
that referenced
this pull request
Feb 24, 2022
The person equality check returns true if the name or the email matches. The OR condition complicates the equality check done when editing a person as it assumes isSamePerson() to have a transitive relation. Alternative 1: Improve the way the equality check is done in the edit command to prevent the above bug. (PRs nus-cs2103-AY2122S2#68, nus-cs2103-AY2122S2#69) Alternative 2: Simplify the equality check by removing the OR condition. This is simpler but possibly too strict for the address book domain i.e., increases the risk of duplicate entries for the same person creeping into the address book We decided to go with the alternative 2 because, * It is important to keep the code base simple, to reduce the initial learning curve of the students at the start of their project * Students can introduce a more sophisticated equality check that matches their product domain later. Also, let's change the default name in PersonBuilder utility class. This is because AddCommandIntegrationTest populates its model using getTypicalPersons() which contains a person with the default name. This test then creates another person using the default name, to be added into the model, which is expected to pass. However, the above update in equality causes this test to fail. Thus we need to change the default name to a unique name that is not inside getTypicalPersons(). Also, the default email is changed for consistency in naming the default values, it does not affect current test cases.
aditi2313
added a commit
to aditi2313/tp
that referenced
this pull request
Feb 25, 2022
The person equality check returns true if the name or the email matches. The OR condition complicates the equality check done when editing a person as it assumes isSamePerson() to have a transitive relation. Alternative 1: Improve the way the equality check is done in the edit command to prevent the above bug. (PRs nus-cs2103-AY2122S2#68, nus-cs2103-AY2122S2#69) Alternative 2: Simplify the equality check by removing the OR condition. This is simpler but possibly too strict for the address book domain i.e., increases the risk of duplicate entries for the same person creeping into the address book We decided to go with the alternative 2 because, * It is important to keep the code base simple, to reduce the initial learning curve of the students at the start of their project * Students can introduce a more sophisticated equality check that matches their product domain later. Also, let's change the default name in PersonBuilder utility class. This is because AddCommandIntegrationTest populates its model using getTypicalPersons() which contains a person with the default name. This test then creates another person using the default name, to be added into the model, which is expected to pass. However, the above update in equality causes this test to fail. Thus we need to change the default name to a unique name that is not inside getTypicalPersons(). Also, the default email is changed for consistency in naming the default values, it does not affect current test cases.
Update AboutUs
Skeletal ivorppp
Update readme
- Update UserGuide with draft UG for v1.1
Update UserGuide and Skeletal PPP
Add acknowledgement and update _config.yml to fit project.
Update DG and PPP
- Add AddTaskCommand
- Add AddTaskCommandParser
- Add model.task.Task
- Add model.TaskList
- Modify Model (Interface)
- Modify ModelManager
- include TaskList in constructor
- Add javadoc comments - Rearrange import statements
- Add AddTaskCommandTest
Add "add task" command
Fix update bug
- Minor fix to the UG command summary - Add page breaks - Update DG non-functional requirement based on the requirement stated on CS2103 website
Update UG and DG
Update PPP and Update Model Class Diagram to reflect Task
Final ug and dg update
Add page break
Add page break
Update page break in UG
Remove Page break
update PPP
Update Statistics
Update UG with page break
Update DeveloperGuide.md
Update dg diagram
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NUScheduler is a desktop app for Year 1 Computing students to assist with more efficient management of tasks and contacts, optimised for use via a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, NUScheduler can schedule your tasks faster than traditional GUI apps.