-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lit Yaw Cheng] Duke Increments #149
base: master
Are you sure you want to change the base?
Conversation
Add toolVersion block in to Gradle code sample to prevent errors.
Change file mode on `gradle` to be executable (nus-cs2103-AY1920S2#9)
Gradle defaults to an empty stdin which results in runtime exceptions when attempting to read from `System.in`. Let's add some sensible defaults for students who may still need to work with the standard input stream.
Add configuration for console applications
The OpenJFX plugin expects applications to be modular and bundled with jlink, resulting in fat jars that are not cross-platform. Let's manually include the required dependencies so that shadow can package them properly.
* tag 'branch-Level-8': Level-8
* tag 'Level-9': branch-Level-9 # Conflicts: # src/main/java/TaskList.java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job! Overall looks well structured and followed coding standards. Long functions can be broken down into smaller functions to make things readable as well as have abstractions.
src/main/java/Duke.java
Outdated
if (arrString[0].equalsIgnoreCase("bye")) { | ||
ui.goodbyeMessage(); | ||
break; | ||
} else if (arrString[0].equalsIgnoreCase("list")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this part can be better refactored, it looks like arrow-head style and feels really long and wordy to read. Like for example you can leave printing things purely to the Ui and just pass it the string that needs to be printed.
src/main/java/Duke.java
Outdated
saveToFile.usingFileWriter(sb.toString()); | ||
ui.showLine(); | ||
} | ||
} else if (arrString[0].equalsIgnoreCase("done")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how you used .equalsIgnoreCase to ensure that varied user input is captured as well.
src/main/java/Duke.java
Outdated
} else if (arrString[0].equalsIgnoreCase("event")) { | ||
try { | ||
String[] eventString = arrString[1].split("/"); | ||
Event event = new Event(eventString[0].strip(), eventString[1].substring(2).strip()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you stripped off trailing whitespaces to keep only the essential user input.
src/main/java/TaskList.java
Outdated
|
||
public ArrayList<Task> tasks = new ArrayList<>(); | ||
|
||
Ui ui = new Ui(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it doesn't really make sense to have a Ui in your TaskList. You could consider sending your ui outputs out from this class first to a higher level that sends them to the Ui, or you could make your Ui methods static such that you don't have to explicitly create a Ui object in every file you want to use it.
import java.util.Scanner; | ||
|
||
|
||
public class SaveToFile { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that this class can have a better name, maybe just storage?
Todo readTodo = new Todo(todoSplit[1]); | ||
readTodo.isDone(todoSplit[0]); | ||
arr.add(readTodo); | ||
} else if (fileStringArr[1].equalsIgnoreCase("D]")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cases for D and E are similar to a certain extent so you might want to consider refactoring this part. For example you could make a general parser method that calls different parsing methods based on what kind of task it is, to make your code more organised.
public Event(String description, String at) throws DukeException { | ||
super(description); | ||
if (at.equalsIgnoreCase("")) { | ||
throw new DukeException("No date"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you made your own exception and used it but I feel that there can be more! For example having different exceptions for different reasons so that you don't do a so-called Pokemon exception handling.
branch-A-Assertions
A-CodeQuality
No description provided.