[Sherwin Poh Kai Xun] iP #470
Conversation
…y them back to the user when requested
Ui: deals with interactions with the user Storage: deals with loading tasks from the file and saving tasks in the file Parser: deals with making sense of the user command TaskList: contains the task list e.g., it has operations to add/delete tasks in the list Command: contains all commands
src/main/java/duke/Storage.java
Outdated
| * @param data_folder_path Path to the data folder. | ||
| * @param data_file_path Path to the data file. | ||
| */ | ||
| public Storage(String data_folder_path, String data_file_path) { |
src/test/java/duke/StorageTest.java
Outdated
| import static org.junit.jupiter.api.Assertions.fail; | ||
|
|
||
| public class StorageTest { | ||
| private final static String TEST_DATA_FOLDER_PATH = "./dataTest"; |
There was a problem hiding this comment.
I think you shouldn't use private final static, but private static final: https://google.github.io/styleguide/javaguide.html
| return (isDone ? "X" : " "); // mark done task with X | ||
| } | ||
|
|
||
| public boolean getDoneStatus() { |
There was a problem hiding this comment.
Shouldn't boolean methods sound like booleans? Any reason why you didn't do something like isDone or hasCompleted?
| return "|" + getStatusIcon() + "|" + description; | ||
| } | ||
|
|
||
| public boolean matches(String query) { |
There was a problem hiding this comment.
Again, shouldn't boolean methods should sound like booleans? Perhaps a more intuitive or explanatory method name here?
src/test/java/duke/DukeTest.java
Outdated
| @@ -0,0 +1,7 @@ | |||
| package duke; | |||
|
|
|||
| import static org.junit.jupiter.api.Assertions.*; | |||
There was a problem hiding this comment.
Should we use individual imports instead of wildcard imports?
| ArrayList<Task> matchingTasks = tasks.getMatchingTasks(query); | ||
| showTasks(matchingTasks); | ||
| } | ||
| } |
There was a problem hiding this comment.
I like that you have a consistent naming system for methods!
| matchingTasks.removeIf(task -> !task.matches(query)); | ||
| return matchingTasks; | ||
| } | ||
| } |
There was a problem hiding this comment.
I like that you use verbs for all your method names!
src/main/java/duke/AddCommand.java
Outdated
| case "todo": | ||
| newTask = new Todo(description); | ||
| break; | ||
| case "deadline": | ||
| newTask = new Deadline(description, date); | ||
| break; | ||
| case "event": | ||
| newTask = new Event(description, date); | ||
| break; | ||
| default: | ||
| throw new DukeException("Invalid task type provided!"); |
There was a problem hiding this comment.
Coding standard for CS2103 requires switch statements to not have tab for case, take note to edit the default IDE settings!
| * Represents a deadline task. | ||
| */ | ||
| public class Deadline extends Task { | ||
| protected LocalDate by; |
There was a problem hiding this comment.
Should perhaps be private since there is already a getter method that exposes this variable
| @Override | ||
| public boolean matches(String query) { | ||
| return super.matches(query) | ||
| || by.format(DateTimeFormatter.ofPattern("MMM dd yyyy")).toLowerCase().contains(query.toLowerCase()) | ||
| || query.equalsIgnoreCase("deadline"); | ||
| } |
There was a problem hiding this comment.
A comment to explain this logic would be great
| * @param ui UI component. | ||
| */ | ||
| @Override | ||
| public void execute(TaskList tasks, Storage storage, Ui ui) { |
There was a problem hiding this comment.
| public void execute(TaskList tasks, Storage storage, Ui ui) { | |
| public void execute(TaskList tasks, Storage storage, Ui ui) throws DukeException { |
src/main/java/duke/Duke.java
Outdated
| private Storage storage; | ||
| private TaskList tasks; | ||
| private Ui ui; |
| throw new DukeException("I'm sorry, but I don't know what that means :-("); | ||
| } | ||
| } catch (DateTimeParseException e) { | ||
| throw new DukeException("Date provided should be in YYYY-MM-DD format."); |
There was a problem hiding this comment.
Is there perhaps a better way to do the error handling?
Current Duke codebase has many implicit assumptions about the Internal Invariants and Control-Flow Invariants. Unverified assumptions may cause bugs to be undiscovered during development and cause issues for the user in production. Let's add assertions throughout the codebase to verify these assumptions. Thorough checking of assumptions using assertions can ensure that bugs in the code are discovered quickly.
Current code has areas of improvement with regards to readability and code duplication. Poor readability would make the code less maintainable and comprehensable to others. Code duplication may lead to greater effort to adjust duplicated code in future. Implemenented SLAP, abstracted more logic to make code at each level simpler, removed duplicated code. SLAP, abstractions and DRY principle makes code more readable and improves code quality.
Add Assert feature
Improve code quality
Implement undo command
DukeMaster
DukePro frees your mind of having to remember things you need to do. It's,
All you need to do is to is,
And it is FREE!
Features:
Here's the main method that sparks the program off!