iP review comments dashboard

Constant names should be all uppercase. (Under Naming in Coding Standard)

Likewise, constant names should be all uppercase. (Under Naming in Coding Standard)

Missing header comment for Duke class, AKA javadocs. (Under Comments in coding standard)

Missing header comment for Deadline class, AKA javadocs. (Under Comments in coding standard)

Add an empty line between description and parameter section. (Under Comments in coding standard)

No need indentation for case. You can configure your IDE style settings for this. (Under Layout in coding standard)

Missing header comment for DukeException class, AKA javadocs. (Under Comments in coding standard)

Missing header comment for Event class, AKA javadocs. (Under Comments in coding standard)

Add an empty line between description and parameter section. (Under Comments in coding standard)

Constant names should be all uppercase. (Under Naming in Coding Standard)

Missing header comment for Storage class, AKA javadocs. (Under Comments in coding standard)

Add an empty line between description and parameter section. (Under Comments in coding standard)

Add a white space in front of if. (Under Layout in coding standards)

Add an empty line between description and parameter section. (Under Comments in coding standard)

Add a white space in front of if. (Under Layout in coding standards)

Add a white space in front of if statement. (Under Layout in coding standards)

Add a white space in front of if. (Under Layout in coding standards)

Missing header comment for Task class, AKA javadocs. (Under Comments in coding standard)

Use meaningful names instead of a character, for instance task. (Under Naming in coding standards)

Use meaningful names instead of a character, for instance taskSymbol. (Under Naming in coding standards)

Use meaningful names instead of a character, for instance isDoneSymbol. (Under Naming in coding standards)

Missing header comment for Tasklist class, AKA javadocs. (Under Comments in coding standard)

Add an empty line between description and parameter section. (Under Comments in coding standard)

Use meaningful name instead of ls, for instance tasks. (Under Naming in coding standards)

Use meaningful names instead of a character, for instance result. (Under Naming in coding standards)

Add a white space in front of if. (Under Layout in coding standards)

Add a white space in front of for. (Under Layout in coding standards)

Use meaningful names instead of a character, for instance string. (Under Naming in coding standards)

Missing header comment for Todo class, AKA javadocs. (Under Comments in coding standard)

Constant names should be all uppercase. (Under Naming in Coding Standard)

Static imports should be above other imports. (Under Package and Import Statements in coding standards)

Missing header comment for StorageTest class, AKA javadocs. (Under Comments in coding standard)

You can add more description to the name using three part format. (Under Naming in coding standard)

Use meaningful name instead of ls, for instance tasks. (Under Naming in coding standards)

Hi all, I apologise for repeating comments and if I offended anyone. My intention was to make it easier to fix if I were to point which were areas that could be improved. Sorry! >.<

No pls dun be sorry! And yeah haha lets stop the thread, psps!

You can create multiple DukeException children classes instead of compiling all the possible exceptions and error messages in one class. For instance, DukeBadCommandException.

Could add a header, AKA javadocs to describe the class.

Could add a header here too, aka javadocs to describe a Deadline Command.

Could add a header here too, aka javadocs to describe a Delete Command.

Could add a header here too, aka javadocs to describe a Done Command.

Could add a header here too, aka javadocs to describe a Event Command.

Could add a header here too, aka javadocs to describe a Find Command.

eventTime might not provide enough context to the class attribute as it includes date of the event as well. Perhaps eventDateAndTime would be a more suited name.

deadlineString might be misleading as it could mean the description of the task. A more appropriate name would be deadlineDateAndTime.

Could add a header here too, aka javadocs to describe a List Command.

Could add a header here too, aka javadocs to describe a Find Command.

Similarly, would be easier to identify the context of the variable if the name is dateAndTime.

Could include time in the variable name to make the context cleaer as well

Could include header here, aka javadocs to describe TasklistTest,

Any reason why you use CommandExecutor instead of just an execute command? Command.execute() seems simpler than Command.getCommandExecutor().execute()?

Any reason why you use the default modifier instead of private as you have a getter method?

Perhaps you mean INDENT ?

Perhaps the work in the Ui and Duke can be redistributed? As of now Duke.java is just the launcher for the real Duke program?

Perhaps "Hello from\n" can also be a constant to maintain consistency?

Can add "\n" to the constants?

Perhaps can use switch case without all the methods?

Can add JavaDoc comment for this method?

Can remove this extra line?

Can add JavaDoc comment for this method?

Any reason why this method has the default access modifier instead of public?

Can add @param in the javadoc?

Missing s from "Get"?

Missing s from "Remove"?

Missing empty line?

Extra empty line?

Can add @return?

Can add @param for task list?

Can add Javadoc of the class?

Can add @return?

Can add empty line?

Can add @return?

Can add Javadoc of the class?

Can add Javadoc for the method?

Can add @return?

Can add javadoc for the class?

Can add javadoc for the method?

Can add javadoc for the class?

Can add javadoc for the method?

Can add javadoc for the class?

Can add javadoc for the method?

Can add javadoc for the class?

Can add javadoc for the method?

Nice updating of readme to teach users how to run the file.

'''suggestion

        return "[D][✓] " + super.getName() + "(by: " + printDateTime() + ")";

'''

Might be better to split long strings rather than short strings.

Might be better to use a switch statement here instead of adding else ifs.

Maybe considering not using * imports

'''suggestion

        return "[T][✓] " + super.getName();

'''

I think it looks cleaner when put short strings in a single set of ""s.

Might want to end the statement with a '.'

Might want to list imported classes explicitly.

Might want to end the statement with a '.'

'''suggestion

Command that closes Duke.

'''

Might want to end the statement with a '.'

'''suggestion

 * Returns whether this is an exit command.

'''

Might want to end the statement with a '.'

'''suggestion

Interface for all command classes.

'''

Might want to end the statement with a '.'

'''suggestion

Command that delete a task in task list and storage.

'''

Might want to end the statement with a '.'

'''suggestion

 * Initializes a DeleteCommand with the given index.

'''

Change 'an' to 'a'.

Might want to end the statement with a '.'

'''suggestion

 * @param index the index given.

'''

Might want to end the statement with a '.'

'''suggestion

 * Returns whether this is an exit command.

'''

Might want to end the statement with a '.'

'''suggestion

 * @return false at all times.

'''

Might want to end the statement with a '.'

'''suggestion

 * and print the response using the given ui.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param taskList the task list to be updated.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param ui the ui that handles inputs and outputs.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param storage the permanent storage of task list.

'''

Might want to end the statement with a '.'

'''suggestion

 *                      or the task list cannot be saved to the storage.

'''

Might want to end the statement with a '.'

'''suggestion

import duke.component.*;

'''

Might want to list imported classes explicitly.

'''suggestion

Command that complete a task in task list and storage.

'''

Might want to end the statement with a '.'

'''suggestion

 * Initializes an DoneCommand with the given index.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param index the index given.

'''

Might want to end the statement with a '.'

'''suggestion

 * Returns whether this is an exit command.

'''

Might want to end the statement with a '.'

'''suggestion

 * @return false at all times.

'''

Might want to end the statement with a '.'

'''suggestion

 * and print the response using the given ui.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param taskList the task list to be updated.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param ui the ui that handles inputs and outputs.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param storage the permanent storage of task list.

'''

Might want to end the statement with a '.'

'''suggestion

 *                      or the task list cannot be saved to the storage.

'''

Might want to end the statement with a '.'

'''suggestion

import duke.component.*;

'''

Might want to list imported classes explicitly.

'''suggestion

import duke.component.*;

'''

Might want to list imported classes explicitly.

'''suggestion

 * Initializes an AddCommand with the given new Task.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param newTask the new task given.

'''

Might want to end the statement with a '.'

'''suggestion

 * Returns whether this is an exit command.

'''

Might want to end the statement with a '.'

'''suggestion

 * @return false at all times.

'''

Might want to end the statement with a '.'

'''suggestion

 * and print the response using the given ui.

'''

Might want to end the statement with a '.'

'''suggestion

 * @param taskList the task list to be updated.

'''

Might want to end the statement with a '.'

Nice touch here for plural vs singular

In my opinion, might be better ux to check between 1 and taskList.size() for those who are not used to 0 as starting index

In my opinion, it might be to do the searching within the list command to make other developers find the list command code more easily in case any modification is needed. (Single responsibility principle)

Adding the exception might help in detecting what type of error it is. It might allow easier modification when multiple commands throw the same type of exception.

Might want to add the searching within the list command itself so that other developers who extend/work together on your project will be able to find it more easily.

Nice touch on the single/plural form of the task.

Might want to change it into an abstract class so that you don't have to redefine isExit every time in every class and just take the argument as an input in the constructor.

Might want to use enums to define different types so that editing the message stored on the enum will change all the places where the same error is thrown.

Might want to group similar commands together in a switch rather than using if elses. It might cut down on the code count too

Maybe change this to exclude the question mark so that the class that extends this can just do

"D " + super.toStorageString()

Perhaps you can have a Javadoc comment here?

Perhaps you can have a Javadoc comment here briefly describing the class?

Perhaps you can leave a line between the description and the @return statement?

This line is quite long, while it does not exceed 120 char, do you want to consider using a line break to improve readability?

Perhaps you can include a Javadoc comment briefly describing this class?

This line is quite long, while it does not exceed 120 char, do you want to consider using a line break to improve readability?

Perhaps you can use a more appropriate name instead of "tmp"?

Perhaps you should leave a line between the description and the @param?

Even though the @param in this case is quite self explanatory, perhaps it might be good to include a brief description to make it extra explicit?

Perhaps you should leave a line between the description and the @param line?

Perhaps you should leave a line between the description and the @return line?

This line is quite long, while it does not exceed 120 char, do you want to consider using a line break to improve readability?

Perhaps you can have a Javadoc comment here briefly describing the class?

Perhaps it would be better if you use a more appropriate name instead of list? Such as tasks?

Perhaps you should avoid using single characters as name for your variables?

Perhaps you should leave a line between your import and your Javadoc comment?

Perhaps you should leave a line between your description and your @param line?

This method is more than 30 lines and very lengthy, perhaps you can consider shortening it to improve readability?

Perhaps you should leave a line between your description and your @param line?

This method is more than 30 lines and very lengthy, perhaps you can consider shortening it to improve readability?

Perhaps you should try to avoid deep nesting, as this line is 5 indentations in and you should try avoiding more than 3 indentations?

Perhaps you should leave a line between your description and your @param line?

Perhaps you should leave a line between your description and your @return line?

Perhaps it would be more appropriate to name it tasks instead of taskList?

Perhaps you should leave a line between your description and your @param line?

Perhaps you should leave a line between your description and your @return line?

Perhaps you should leave a line between your description and your @param line?

Perhaps you should leave a line between your description and your @return line?

Perhaps you should leave a line between your description and your @param line?

Perhaps you should leave a line between your description and your @return line?

Perhaps you can use a more descriptive name such as scanner?

Perhaps you should leave a line between your description and your @return line?

Perhaps you should leave a line between your description and your @param line?

Should this be Runs instead of Run?

Did you accidentally leave a space here between "time" and "the"?

wrong order of import (alphabetical)

damn optional 0.0

missing javadocs for methods in this class

missing javadocs

missing javadocs for methods in this classs

missing spaces between parentheses and brace

use an import rather than referring to duke.TaskType

is there a better name than string? this isn't very informative

i think my tutor mentioned that 'list' as a collection name isnt very intuitive and informative.

consider referencing instance level variables with this. to mitigate variable shadowing and be clearer

Missing javadoc for class, similarly for other classes too.

Consider naming variables differently to the class name for clarity

consider extracting the addShowOnScreen to the parent class AddCommand, or Command itself

Consider giving this boolean a more meaningful name

variable name "by" is not very intuitive. maybe use "dateString"

missing @Override tag

method name should be a commanding word starting with a verb, such as 'getStringForPrinting'

can consider naming variables differently to the class name to avoid confusion

this is a repetition of the if-else condition in line 33, consider merging them

exception should be specific with a message string to avoid confusion

caps "If", similar for other docs too

unintuitive variable name for a stringbuilder, sounds more like a collection of tasks instead.

consider changing theses if-else to a switch statement for clarity

method name should sound like a boolean, consider "isValidAddTaskCommand"

I think the exceptions thrown should be as specific as possible

try to use present tense

can consider adding exception handling here

each enum be on a new line

should include expected behaviour, similarly for the method names below

I think it might be better to use a stronger word as as "InvalidCommand", rather than "unknown", which can give the feeling of the command being unhandled?

consider using string.format for this

variable name 't' is not very clear

i think its better to reference your instance variables starting with the "this" keyword, such as this.ui to be clear and prevent variable shadowing

'c' is not a very intuitive variable name. if i rmb correctly, single character names should only be used for scratch variables

main method as an entry point should be separate from the other class level and instance level methods. consider moving it to the bottom

'c' as a variable name is not the most intuitive

remove commented out code?

consider writing this in line with String.format for clarity

un-intuitive variable name

convention to call super() as first line in constructor

consider using switch rather than if-else. this is slightly hard to read

whats the use of protected here?

shouldn't have return statements in constructors

since this is repeated for all the events, consider declaring as static final.

can simply return description.contains(keyword) without the need for conditional expression.

consider moving this to your parser!

consider renaming to add to follow the naming conventions in Collections

idx is not very intuitive 😕

missing javadoc for test methods

I think you can consider reorganising these if else statements. The else is quite unnecessary in this case.

Maybe you can encapsulate the logic in a method initialiseDate

Is tasks really needed for all commands? I am referring to commands like help. I would suggest to add tasks as a field in classes that inherit from Command and initialise it with a constructor in the class.

Similar to tasks above, is parser really needed for all commands?

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public constructor

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public method

the @param should end with a full stop

e.g. @param inputLine The user's input.

similar to the @param, the @return should end with a full stop

The parse method look long and complicated, maybe you can try to refactor by extracting methods.

e.g. addDeadline method for case deadline

Similarly to parse in Parser.java, maybe you can try to refactor loadData by extracting the methods.

Instead of using a for loop and breaking the abstraction barrier, you can encapsulate getting the whole task list as a string in a method in TaskList.java.

I think that the testing is insufficient. Maybe you can add extra tests.

e.g. for deadline command

deadlineedasfa

deadline awrfawesf

deadline dads /by

deadline efaws /by

deadline /by 2020-10-22

deadline/by 2020-10-22

deadline dda /by 2020-22

deadline dda /by 2020-10-22

Missing javadocs for public class

Missing javadocs for public constructor

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public constructor

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public method

Missing javadocs for public constructor

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public method

Missing javadocs for public class

Missing javadocs for public method

Should there be a Javadoc comment here?

Should there be a trailing whitespace here? Also, perhaps it might be good to add a new line to end of file.

Should there be a Javadoc comment here?

Should there be a new line at the end of file?

Should there be a Javadoc comment here?

Should there be a trailing whitespace here? Also, perhaps it might be good to add a new line to end of file.

Should the variable 'in' and 'taskList' be private and have accessor methods?

I think the line below has more than 120 characters. Perhaps it might good to split this line up into two and place half in a new line?

Should there be a new line after end of file? It seems to be prevalent among most of the files, so perhaps it might be good to ensure it in every file.

Should variable 'file' be private and have accessor methods?

Should there be a Javadoc comment here?

Should each variable declaration be in its own statement?

Should switch and case statements have the same indentations?

Should there be a default clause at the end of switch statements?

Should there be a Javadoc comment here?

Should variable 'lst' and 'storage' be private and have accessor methods?

Should there be '{}' for the if statement?

Should there be a javadoc comment here?

Should there be '{}' for the if statement?

Should there be a javadoc comment here?

Should there be '{}' for the if statements?

Should there be a javadoc comment here?

Should there be Javadoc comments for all public methods?

Should import statements be arranged in this order?

Should there be a JavaDoc Comment here?

I think you might want to add newline at end of file

Perhaps also adding a newline at the end of file would be good?

The newline issue seems to be prevalent among other files, so perhaps it might be good to go about adding them to all the files.

Should there be a Javadoc comment here?

Should the import statements be arranged this way?

Should there be a Javadoc comment here?

Should the import statements be arranged this way?

Should there be a Javadoc comment here?

Agreed! Organising your code into packages might improve the manageability and readability of your code! Even though it is optional, it's a good practice 👍

Perhaps this variable can be declared as private instead? Since it is only used within the scope of Deadline class. If you want to make it accessible to another class, you can write a getter method instead.

I really like that you ordered import statements consistently. However, even if it is not compulsory, I think it is better to order your import statements in lexicographical order to make it look neater.

Perhaps it would be better to separate this method into different classes (Parser, Ui, Storage, TaskList, etc), following the OOP principle as required by the module (even though I know it exceeds the minimum requirements). However, it is a good practice and separating it would make debugging, managing, and testing a lot easier. It might take more effort now, but you won't regret it! Cheers 😄

Perhaps it is better to rename the variable names to "file" and "scanner" to enhance readability and clarity.

I think it is better to rename the variable name into "parsed/splittedTask" or "parsed/splittedInput" to avoid confusion 😃

Instead of accessing task[0], task[2], etc multiple times. I suggest you store them in variables (e. g. commandType, etc) to make improve readability and make debugging easier (you won't have to remember what is task[0] refers to). You can also consider using switch statement!

I think it is redundant to use an array for just one string. Maybe you can consider changing greetingText to a string? I noticed the same issue in several other places too.

May I ask why do you need 2 scanners in 1 class? I think it is better to just use one scanner to avoid confusion 👍

Maybe you can write the variable as receivedMessage instead?

In my opinion, I think it is a bit redundant to create a class for Response. Perhaps you want to consider storing them as a static variable instead? (e. g. private static final String BYE_MESSAGE = "...."😉 😃

Perhaps it is better to name it as "foundTasks" instead? I was a bit confused at first.

Perhaps it would be better if you throw all the Exception? They might be useful in the future use (for try-catching). I noticed the same issue in several other places too.

Agreed. You can write a getter method to get the type of the Task and just move the writeMessage (would be better if you change the name to "getMessage") to Task class. It's more OOP that way 👍

In my opinion, it's better if all your exception extends DukeException.

I think it is redundant to assign "done" to an empty string. You can just leave it as variable declaration only.

May I ask why do you put empty string as your parameter? 😄

Perhaps you want to consider changing the access modifier to private instead?

Perhaps you want to consider using switch statement?

Just an advice, this might not be a coding standard violation, but I think it is better if you make Task class an abstract class.

In addition, it is better to change the access modifier of variable description and isDone (on Line 3 and 4) to protected (following encapsulation fundamental, it is not advisable to declare your variable public)

You can write "../src/main/java/*.java" instead, to support extension to your code, so that you don't need to keep adding lines when creating new classes 😃

I think it is better to add access modifier to your variables (private, preferably) to comply with coding standard (and encapsulation) 😄

It's missing the newline at the end of the file. You might want to consider doing checkstyle in IntelliJ as it highlights all coding style violation! (makes our life easier) 😄

In my opinion, you don't need the message attribute since Exception has it.

Following the previous comment, there is no need to write toString() method since Exception class already has a built-in function getMessage() to fetch the error message.

It is good that you group the import statements consistently. However (this is just nitpicking, not compulsory), it looks neater if you write them in lexicographical order.

May I ask why do you leave these cases empty? Is it because Todo, Deadline, and Event are considered as AddCommand? Perhaps you might want to consider separating them (TodoCommand, DeadlineCommand, EventCommand extending from AddCommand) to make it more OOP.

Perhaps you might want to consider renaming this variable to something like "parsedInput" or "splittedInput" to avoid confusion? (stringArray is a bit too general) 😆 I noticed the same issue in several other places too.

To avoid repetition, you might want to consider making the parsedInput as class variable. So you don't have to parsed multiple times.

I think it is better to avoid magic number because it is confusing. Just like my previous comment, I think it is better to store the parsedInput to make debugging easier! I noticed this same issue in several other places too, you might want to consider this! 😄

I think it's really great that you abstract this to methods! It makes debugging easier (you might want to avoid magic number though!)

To make it sounds more like boolean, you might want to rename this to "hasDirectory" instead.

I think this part is great since it is easy to read. Just some nitpicking, though, I think it is better if your error message is more specific so the user can know the problem! 👍

Perhaps it is better to rename the method to "readDataToList"?

Assuming these are constants (since they won't change), I think the variable names must be all uppercase (e. g. DIVIDER and LOGO)

To make this variable sounds more boolean, you might want to consider renaming this to isExit.

I see that you do taskList.getListSize() several times. I think it is better to store it as a variable listSize to avoid calling getListSize() multiple times.

It's a good practice to avoid using * when importing. You should only import statements that you are going to use! 😄

May I ask what is GetCommand for? Correct me if I'm wrong but assuming this is for finding task, perhaps you might want to consider renaming this class to FindCommand to avoid confusion. Since get is a bit ambiguous (can also be interpreted as a verb).

May I ask what is the difference between both of these commands? Maybe you want to rename it something more intuitive (SHOW, FIND_KEYWORD, FIND_DATE, etc) ?

You might want to change this class to an abstract class because it doesn't make sense to create a new a Task. It is algo a good practice in OOP because it reduces code repetition.

Don't forget the access modifier! 😄 It is important as attributes should be declared private when possible and neglecting access modifier makes the attributes implicitly public.

You might want to consider renaming this to comply with the coding standard. Method name should be a verb and intuitive.

Should there be 'No blank line between the documentation block and the method/class'?

Naming of fold might be unclear?

naming of var list can be more specific?

Will it be clearer if 'current' is named 'currentTask' instead?

Is 'finsih' a typo?

Naming of method 'tasks' can be misleading. Perhaps it should 'explain the named entity to the reader accurately and at a sufficient level of detail.'?

Naming of var 'type' is not descriptive?

Will it be better if it is "currentTask" instead of "current"?

should it be "keyword" instead of "keyWord"?

"finding" is not descriptive of what it does?

I think is good to have the header and @author tag in the JavaDoc of the class.

Should there be a fullstop behind each param line because "Punctuation behind each parameter description"

Should there be an 'empty line between description and parameter section'?

Maybe can put as "@param args Unused." instead?

Should there be an 'empty line between description and parameter section'?

Should there be a fullstop behind each param line because "Punctuation behind each parameter description"

Should there be an 'empty line between description and parameter section'?

Should there be a fullstop behind each param line because "Punctuation behind each parameter description"

Should there be a description for return?

Should there be an 'empty line between description and parameter section'?

Should there be a fullstop behind each param line because "Punctuation behind each parameter description"

Should there be an 'empty line between description and parameter section'?

Should the description for return be empty?

Should there be an 'empty line between description and parameter section'?

Should be "Returns..." as "In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)"?

You could consider packaging the code to improve readability

Probably one thing you could consider could be to extend ArrayList from taskManager to reduce the amount of code needed to be written

The parser can possibly be placed in its own class to aid with the parsing of the dateTime objects when they start coming in

Please consider writing javadocs to aid people reading your code

Good use of overloading the toString method

You could probably consider creating custom exceptions.

One thing to consider here would be that you could override your toString method to save time and code later on

The javadocs are quite professional since you added the version as well as your name.

Maybe there's no need to mention the package name. One suggestion could be to package your code more.

Does this WhileLoop: do anything in the code? I have never seen it before so I am not sure

Probably using shorter variable names could boost code readability.

One suggestion would be to use the parser class to entirely take care of the logic as well as making full use of the UI class to scan in your input.

You could try creating custom exception in which case you would not have to do a nested try and catch and instead you would get to do something like

'''

try {

Your code

} catch (IllegalFormatException ex) {

 System.out.println(Error Message);

} catch (IllegalTaskException ex) {

 System.out.println(Error message);

}

'''

Just to repeat the point that making a custom exception would be a really great idea.

Probably you could consider how to differentiate between Event, Deadline by overloading a method in your Task class instead of using instanceOf. Using instanceOf is normally a last resort so please consider using an overloaded method to distinguish between a deadline, task and even todo.

Probably putting it into an exception package would improve like understanding of your code especially when gradle is implemented.

Good use of javadocs again. Probably a bit more description might be needed but otherwise it is good practise to have documentation on almost all your non trivial methods and constructors.

Maybe remove this constructor since Java does it for you by default

Probably a typo but String is repeated twice here

One big suggestion from me would be to expand on what your parser class does. So far from what I can see its more of a String trimmer or splitter which is quite a basic functionality. Think about how you could build on it like using the parser to get your LocalDateTime object from input and so on.

Probably removing the javadocs for trivial methods like getters and setters. This is just a small suggestion.

Please reconsider the use of instanceOf.

One way to reduce this duplicate code would be to overload the toString method in your TaskList class.

Very comprehensive set of methods to show error messages and so on. Probably recieving user input here would fit in well with the OOP principles and increase modularity of your code.

Quite a few methods tested but probably the name of the Test file is a bit misleading since you are testing more of the tasks than the actual duke functionality. Probably renaming it to TaskTest would be more apt.

Love the twist given to the name. 👍

Could consider removing javadocs for functions like public static void main which are ubiquitous in Java.

More detailed description of each param would aid readability of the code

Could consider making a custom exception here instead of throwing a DuckieException.

Instead of repeating the input.toLowerCase() maybe you could assign it to a variable at the start itself making it more readable.

The use of a command class is very good OOP practice. 👍

One suggestion here could be to consider the fact that the mkdirs and createNewFile functions already make a new directory/file if it doesnt exist.

I am sorry but I noticed that you have copy pasted this same comment like multiple times so far. Mentioning it once or twice already makes the point I feel.

Sorry for pointing out a trivial issue but the previous function of getHorizLine would probably be enough for your code to function. Probably consider removing the method.

Nice usage of packaging. 👍

It depends on your reasoning as well but this approach would probably have a greater run time than perhaps just storing all the lists in the end when the user inputs the "bye" command.

Good use of Javadocs

There might not really be a need to override this method since you won't be really printing out the exception object created.

Probably you could consider initializing the INDENT variable just once in the DuckieException and then using it from there in all the other exceptions that extend it.

Could consider if TaskList should be placed inside the task package or along side the duckie class

Could consider getting rid of this test class since it actually is just a dummy test that doesn't really test any of the features in your actual code

Very comprehensive testing of tasklist. 👍

Is it better and clearer if sc is renamed as scanner?

Will it make more sense if the variable renamed as listOfTasks?

Is it better and clearer if ans is renamed to answer?

Is it better and clearer if d is renamed as deadlineTask or other specific name?

Is it better and clearer if e is renamed as event or other specific names?

Would it be better if each + sign indents a new line?

Is it better if the @Override of toString() can be specified?

Is it better to place a white space between the close bracket and the open curly brace?

Is it better to place a white space between the if and open bracket, as well as between the close bracket and the open curly brace?

Is it better if an empty line is placed to separate the code above the comment and the comment?

Is it better if the access of the constructor is specified?

Is it better if an empty line is placed separate the description and the param explanation?

Is it better to use a more formal java doc to explain the method?

Is it better if we can have an empty line to separate the description and the @param?

Is it better if the access of the constructor is specified?

Is it better we have an empty line to separate the description and @param?

Is it more specific to rename c as command?

Is it better if the @Override can be specified?

Is it better if you specify the access?

Is it better to have a formal java doc?

Is it better if the @Override can be specified?

Is it more readable if tmp is rename as a specific word?

Is it more readable if db is rename as a specific word?

Maybe you also want to have an explanation on the parameter?

Is is better if an empty line can be placed to separate the description and @param?

Would it be more readable and clearer if there is an empty line in between each case?

Maybe it is better to break down this long method into different shorter methods?

Is it better if the empty line is closed?

An empty line can be added to separate the description and the @param

Is it better if an empty line can be added to separate the description and the @param?

Maybe you want to add an empty line to separate the two methods so it is more readable?

Would it be more readable if your can declare each string as a variable?

Can have an empty line to separate the import and main code

Maybe "Creates a Duke object" instead? Makes it clearer

Caps "If"

"@return Boolean indicating whether the program should terminate" would help to improve clarity

Caps "To"

Caps "Default"

Maybe "Creates a DukeList object" instead? Makes it clearer

"True if a task is completed. False otherwise" may help to make it clearer

Can consider changing to "Marks an item as completed" for clarity and better english. But its really a matter of preference here (I prefer to use completed rather than done)

"+" sign formatting is not consistent here, so do relook at it

"Display statistics / tasks in list" will help in improving clarity

private static final String PROJECT_ROOT ...

Overall good formatting / use of Java coding standards for this particular script Storage.java. Good job! 👍🏻 👍🏻 👍🏻

Consider describing what kind of enumerations there are here (ie LIST, DONE, DELETE, TERMINATE, TASK, FIND, INVALID) and what they are used for

This is good elaboration 👍🏻

"Task that needs to be done before a specific date/time."

"Task that start at a specific time and ends at a specific time."

Good job for Task.java. Java coding standards were followed well here 👍🏻

Very very good test code function namings here using featureUnderTest_testScenario_expectedBehavior(). 👍🏻 In fact i'll improve my code namings as well after looking at how you named them for Week 5's ip

Can consider isUserDone as an alternative naming for the boolean

Can consider renaming to writeToTaskStorage(...)

Can consider changing to printWelcomeMessage() so as to make it a verb (ie an action)

Can consider changing to printGoodbyeMessage() so as to make it a verb (ie an action)

Consider abstracting your dividers into a static final variable as there are repetitive usage of it

Can consider changing the naming to printTasks(...) so as to make it a verb (ie an action)

Can consider changing the naming to printTodaysTask(...) so as to make it a verb (ie an action)

Consider executeAddingOfTask(...) for more clarity

Very good formatting here 👍🏻

|| command.split(" ")[0].equals("event"); (Bring the OR operator down)

Consider executeDeletingOfTask(...) for more clarity

Consider markCompletionOfTask(...) for more clarity

Consider executeApplicationExit(...) for more clarity

Will not be commenting on this any further. Hope that my previous comments on execute will help your code clarity 😃

markTaskAsCompleted(...)

getTaskListSize(...)

createTodo(...)

Maybe something like pullTodo(...)? I notice that your Javadocs describe the method really well. I referred to your Javadocs to see how I would name the method so maybe you can consider referring back to your Javadocs for method naming

Good use of featureUnderTest_testScenario_expectedBehavior(). I'll have to change my test code naming for this part as i didn't follow this format :L

To improve it further, i think you can consider describing specifically what kind of exceptions are thrown in ...exceptionThrown()

Perhaps it would be better to separate the import statements.

Good coding standard for variables

Perhaps you can try to rewrite the name of this class name because I don't really understand it.

Perhaps you can try changing the indentation, seems to be a bit off.

Perhaps you can consider deleting this white space.

Perhaps you can consider deleting white spaces

Seems like a wrong JavaDoc comment, you may want to change it.

Correct naming style of constants 👌

Seems like a wrong JavaDoc comment, you may want to change it.

Sometimes you have a gap between the above line and next sometimes you don't, perhaps you want to look into it.

Seems like a wrong JavaDoc comment, you may want to change it.

Perhaps you can think about separating the import statements.

Perhaps try to separate import statements, for better readability.

May consider deleting this white line

Code length seems to be more than 30 lines.

Wouldn't it be better to have a better name for time instead of at?

Perhaps it would be better to have a clearer name for by.

Most of your classes do not have this unnecessary white lines of code at the end. Wouldn't it be better to remove them? I have noticed these in some other classes as well.

Clear method names throughout this class. 👍🏽

Wouldn't it be better to have an else statement, so that it is easier to read?

Maybe you can try changing the name of the method to, formatForList for easier understanding?

Good job in your method names, extremely clear 👍🏽.

I think there is a spelling error in this JavaDoc statement.

Instead of description wouldn't it be better to have a clearer name

Perhaps it would be better to avoid such complex expressions. It is also better and more natural to test for Files.exists(path) rather than !Files.exists(path).

Isn't this an unnecessary white space? I have noticed this in quite a number of places.

Would be better to phrase this into isParseDelete? Applies to the methods above as well.

Perhaps better to add else block as well, to improve readability.

Sometimes you have a gap between the class definition and java doc and sometimes you don't. Perhaps you want to look into it

May consider adding else block for easier code readability, have noticed this in other classes as well.

Perhaps it would be better to separate the import statements.

Perhaps it would be better to separate import statements.

Should there be an empty line between description and params?

Same as above, might be good to leave an empty line between description and params/return statements.

Might want to avoid deep nesting. Possible to separate the unusual conditions and exit separately in an earlier block.

Might want to use "tasks" here to indicate plurality as tasklist was used previously.

Should the imported classes be listed explicitly?

Should the imported classes be listed explicitly? I noticed the same issue in several other places too.

Perhaps consider shifting private to the front of static to be more consistent with the other variables?

Might be better to shift this below the static variable.

Might be good to add in punctuation at the end. I noticed the same issue in several other places too.

Should there be an empty line between description and parameter section? I noticed the same issue in several other places too.

Might want to start first sentence with "Parses" instead. I noticed this in other areas as well.

Perhaps consider breaking the line before the operator "+"?

Is there any header documentation for this Ui class?

Is there any header documentation for this class?

Consider sorting imports by lexicographical order. Noticed this in a couple of areas as well.

Perhaps enclose the if blocks with curly braces?

Consider using a clearer variable name instead of "that".

Any idea when the DukeException will be thrown?

Might want to consider breaking this line as it is longer than 120 characters.

Might want to consider breaking this line for better clarity.

Should the white space before the trailing semi-colon be removed?

Should the white space before the trailing semi-colon be removed? Noticed this in a couple of other areas as well.

Might want to add a space before the opening curly brace.

Is it possible to break this line up?

Perhaps add in the curly braces here? Noticed this in a couple of areas.

Consider breaking this line up.

Perhaps public can be shifted in front of abstract. Noticed this in a couple of areas as well.

Any idea what is the accessibility of this variable?

Perhaps break this line before the && operator?

Is this an unused import?

Is there more than one whitespace between the "=" and "new"? Noticed the same issue below as well.

Any reason why this method getStore is left blank? Noticed a couple of methods below left blank as well.

Think you can create subclasses for Command such as ListCommand / DeleteCommand to handle the various inputs. Should help to make the code more readable and better abstracted. Think that will help to optimize and shorten your code, and prevent having too many constructors for similar purposes

No issues, but just a suggestion to use String.format

I have never seen this syntax before? Is it an meant to be commented out?

Great use of switch case, very readable!

I think you can afford to use "private" instead of "protected" since there is not subclass for Event.

this throwing of error can be abstracted to a subclass DoneCommand (for example), so you can shorten the code for your Parser

Just a suggestion: instead of checking for length, use substring to split the code, thereafter, check if empty.

think this is not required in the code? (or do you face the return nothing error?)

Just a suggestion: I used enum to create TaskType and use Tasktype as part of the printing (further leverage on Liskov Sub Principle)

Javadoc can be added here too

access modifier for your methods can be included

I think can be private instead of protected as your Ui class has no subclass

Like the abstraction for readability!

Wow, thanks for sharing man

feel like your if else is too late, probably can abstract out some stuff to shorten the code.

Great abstraction, the name is very readable

I think you can try catch (DukeEmptyEventException | DukeTimeParseException | ... ) to catch exceptions

Great naming man

Think you can javadoc here if you want LOL

Like the formatting

Interesting way of running Duke haha

Ooo good use of StringBuilder

Access modifier can be added here

Would suggest to use this.list(), was abit confused where the method came from when I read it initially

I would recommend you to create the Command class to better abstract commands such as ListCommand DeleteCommand etc, will help in shortening Parser.java.

I would recommend concatenating the string or using your StringBuilder to construct your input as a whole instead of appending so many times

Access modifier

access modifier

great use of static variables here

access modifier

think you can abstract a separate method here

feels like there are some repetition you can abstract to the super class.

nice testing

Will it be better if there can be more details about the file and path in the parameter description? Additionally, will it be better if there can be a full stop to make the parameter description a sentence?

Should there be a new line between the description of the method and the description of the parameter?

Looks good but it seems that the full stop on this line is missing.

I am not sure whether it will be better to start the method description with a verb instead.

It seems that the pull stop is missing here.

The comment looks good and clear.

Will the new line between the method signature and the variable declaration be necessary?

It seems that punctuation is missing here. I noticed that are also similar problems in several other places.

It seems that this line may be a bit too long here. Will it be better to start a new line?

Will it better to include the method comment here?

Will it be better to include a method comment here?

I am not sure whether there should be a space between the case content and the colon here.

Will it be better to start the class description with the class name here? I have also noticed similar problems in several other places.

Will it be better if there can be a new line between the description of the method and the description of the parameter? I have also noticed similar problems in several other places.

Will it be better if there can be a new line between the description of the method and the description of the parameter and the description of the result?

Will it be better if there can be a new line between the description of the method and the description of the parameter and the description of the result? I have noticed similar problems in several other places.

Will it be better to include a default section here?

Will it be better to give a more descriptive name for the method, such as identifying the command elements and evaluating the command?

Will it be better to include the keyword else here?

Will it be better to include the keyword else here? I have also noticed similar problems in several other places.

It seems that the indentation needs to be adjusted a bit here.

Will it be better to include a keyword break here?

Will it be better to include a keyword break here? I have also noticed some similar problems in several other places.

Will it be better to give a more descriptive name for the method?

Will it be better to give a more descriptive name to the method, such as the name is directory present?

Will it be better to give a more descriptive name to the method, such as the name is file present?

Will it be better to give a more descriptive name to the method and include the sources of the task list in the name?

Will it be better to give an accessor to the variable here?

Will it be better to give a more descriptive name and include the information on which part of the command it represents?

Would it be better if errors such as this were captured in your own exception?

Please avoid using wildcard import statements.

Hi please leave only 1 comment for repeated mistake. Under Best practices for reviewing PRs:

"No need to repeat the same comment many times. It's not the job of the reviewer to clean up after a sloppy author. If you notice the same problem in multiple places, after commenting an a few of them, you can simply say ... I noticed the same issue in several other places too."

Maybe a more meaningful name "completeTask/markAsDone" would be more descriptive?

You can consider using a more descriptive enum name such as "TaskType".

More extensive testing could be done in the future.

This is cool but quite hard to read. Will if statements be more readable if you require more than 1 ternary operation?

You can consider using trim() which should achieve similar outcome.

You can consider using dateformat to reformat your date's presentation. Could potentially reduce errors and it is easier to catch exceptions.

Is it a bit wasteful to create a method that's only for 1 exit command? Can consider using the "instance of" check to exit the app instead.

Will it be better to name the class as "DukeException" or something more specific, since "CustomException" is too broad and does not inform us on the purpose of the exception?

Will it be better to store the tab spacing as a variable, since it is used in other functions as well?

Please avoid using wildcard import statements.

Please indent switch statements according to the Java style guide.

Do you need to check for index out of bounds for cases where u access part[1] e.g. user inputs "done" (just checking I'm not sure if it will cause an error)

Maybe you can consider try-catching the IOException here and throwing a CustomException with a customised message. This way you can better control the error messages.

I'm not sure if catching all exceptions is recommended since it makes debugging harder.

I feel that "by" is not a very descriptive variable name.

I would recommend using the unicode encoding (/uXXX) instead of directly pasting it in as it might not display properly in some cases.

Do you need to check that the user input a invalid taskIndex (e.g. -1 or too large)?

Can this be moved to the parent class instead?

Should this be renamed to "hasKeyword"

Do you need to check for invalid date formats?

Is protected necessary or will private be sufficient?

You can consider using ternary operations to condense this section.

Is it possible to perform the exit command without using a function, since it is the only command that meaningfully uses this function? You can consider using the "instance of" check to exit the app.

Can "by" be a bit vague? You could use a more detailed variable name.

Will a switch statement be more condensed in this case?

Do you need to include this inside every if block, or can you have 1 of this outside the block?

Do you need to mark both the task and the item in tasklist as complete? Since it's passed by reference, marking either as done should suffice (unless you cloned the task at some point).

Should these class variables be declared with a non-public access modifier to adhere to encapsulation principles? Perhaps you could consider using protected or private?

Perhaps you could consider following the guidelines for Java coding standards when writing JavaDoc comments? I think you are missing a 'return parameter' for the JavaDoc comment, or perhaps is there any reason why you wrote the JavaDoc comments in the way you did? I observed the same issue in several other methods as well.

Perhaps you could list out all the imported classes explicitly? I noticed the same issue in several other classes as well.

Perhaps you could consider adding JavaDoc comments for class members as well?

Perhaps you could add a whitespace after 'while'? The guidelines on Java coding standards states that Java reserved words should be followed by a white space. I noticed this issue in other methods containing while, if and if-else blocks as well.

Should there be an extra whitespace after the '&&' operator? I noticed the same issue in other areas as well.

Perhaps you could use Egyptian style brackets for the 'for' loop? Also, maybe you can consider writing the 'if' block on the next line below the 'for' statement? I think this can make the code look cleaner and enhances readability.

Perhaps the conditional else statement body should be put on a separate line, i.e line 128? Also, maybe you could wrap the body of the else statement in curly braces to enhance readability?

Perhaps you can leave this constructor out since Java creates a default constructor if no constructor was declared. However, I do not think this is a serious issue. I noticed a similar issue in the Storage class below as well.

Perhaps you could put the conditional if statement body on a separate line by moving the if block body to the next line, i.e line 33? I noticed this issue in several other areas as well.

Also, perhaps the 2 lines: arr.add(""); and continue; could be written in separate lines to enhance readability.

Perhaps you can consider handling the caught exception in this catch block? Is there any specific reason why you chose not to handle the caught exception? I observed a similar issue in other methods as well, such as on line 65-66 in this same class.

Perhaps this method name is very ambiguous and does not give readers a clear idea on what variable is being retrieved? Perhaps you can use 'getTask' as the method name? I believe this provides more clarity as well. I noticed similar issues in other classes as well.

Perhaps you could shift this constructor to line 11 below the other constructor? Placing a constructor at the bottom of the class might not be ideal for readability.

Perhaps line 9 could be removed so that the '@Test' annotation is directly above the junit test method? This might not be a serious issue though. I observed a similar issue for the TodoTest class below.

I like how all the class names in your code and clear, concise and adhered to the Java coding standards and naming conventions.

Perhaps you could add JavaDoc comments for classes? I noticed some other classes were missing JavaDoc comments as well.

Perhaps you could add an empty line after the JavaDoc header comment to separate the header and the parameter description? Also, I think you might have to add a full stop after all sentences in JavaDoc comments? I observed a similar issue in other JavaDoc comments.

If I am not wrong, I think abstract methods should require JavaDoc comments as well?

Perhaps you could add a whitespace after "if" since it is a Java reserved word? I noticed a similar issue in other areas well.

I think you should add a white space after "while" ? I observed a similar issue in other areas too.

Perhaps you could add a full stop after each sentence in JavaDoc comments? I think this issue was highlighted in the guidelines for Java coding standard. I observed a similar issue in other JavaDoc comments as well.

Perhaps you could consider writing the next if-else block immediately after the closing curly brace of the previous if-else block? I think this is a very minor issue still.

I think the first sentence of the JavaDoc header comment has to start on line 9?

I think you are missing a return description here?

I think there is a wrong indentation on line 208? I believe there should only be 4 spaces indentation.

If I am not wrong, I think the first letter of each sentence of the JavaDoc comments should be capitalized? I noticed a similar issue in other JavaDoc comments as well. Perhaps you could capitalize "given" and "message" in this case?

I think you are missing a JavaDoc header comment here?

Perhaps you could consider adding JavaDoc comments for class variables as well? Just a small suggestion!

I think the closing bracket and opening curly brace should be on line 36 together with the 'for' statement?

Since this is a constant, should we make its name all uppercase?

Lint: See https://github.com/nus-cs2103-AY2021S1/ip/pull/281/files#r480009471

I like the concise name for the parameter here since it's a scratch variable 😄

I think we're missing the method summary here, perhaps it'll be good to include one for readers?

Just realised this is the case with the other class methods too 😬

Lint: See https://github.com/nus-cs2103-AY2021S1/ip/pull/281/files#r480009471

Lint: Perhaps we can add a whitespace after 'while' since its a reserved word?

'''suggestion

    while (task != null) {

'''

I'm not sure if this might help, but would it be good to include line breaks between logical pieces of code in this fxn to improve readability? 😄

Same comment for the other methods in this class too 😬

Oops I actually feel like a short param name seems appropriate since this var is only used once in this one-liner fxn >< But I see your point here 😄 Perhaps adding javadocs to describe the param i might help instead? Just my two cents 😬

Could we use a verb for the method name?

See comment in Deadline.java

Suggestion: could we add logical line breaks to this fxn? Perhaps one way to section it could be:

FXML loading logic
Setting up of nodes
Masking logic

Nit: Is the 2nd semicolon a typo? 😁

I really like how everything here is at the same level of abstraction 👍

To make the happy path more prominent, could we remove the redundant 'else' clause here?

'''suggestion

    if (!super.completed) {

        throw new IncompleteDukeCommandException("Add command was not completed.");

    }

    

    return String.format(

                "Got it. I've added this task:\n  %s\nNow you have %d tasks in your list.\n",

                createdTask.toString(),

                remainingTaskCount);

'''

Perhaps we can name this isCompleted to make it sound more boolean-ish? 😄

To avoid arrow-styled nested code, can we use 'else if' clauses instead of nesting the if-elses here?

'''suggestion

    boolean isExistingTasksEmpty = existingTasks.size() == 0;

    

    if (super.completed && isExistingTasksEmpty) {

        return "Congratulations! You don't have any tasks left to do.";

    } else if (super.completed && !isExistingTasksEmpty) {

        printout = "Here are the tasks in your list:\n";

        for (int i = 0; i < existingTasks.size(); i++) {

            printout += String.format("%d.%s\n", i + 1, existingTasks.get(i).toString());

        }

        return printout;

    }

'''

The new boolean variable is just an optional suggestion to make the conditionals easier to read 😄

I like the constant names, they're very clear 👍

I like that you've included a comment to explain the empty catch block 💯

It took me a few seconds to realise that 1440 = no. of minutes a day (dumb me 😆 ). Perhaps we can declare a named constant for the no. of minutes in a day to make it easier on readers?

Totally optional and just my two-cents though! I understand that it's only used once here. But just wanted to throw it out there since the module dislikes magic numbers

🤣

Suggestion: Can we refactor this as a guard clause and put it at the top (just below the first guard clause on line 57)? It could help make the happy path more prominent

The comment is great at explaining 👍 But since this is the case, perhaps you could just place the return statement in the catch block? Since we aim to avoid unnecessary empty catch blocks

'''suggestion

        // We attempt to parse the string as a LocalDate and compare it to the deadline date,

        // but upon failure, we perform a comparison with the deadline description.

        return searchParameter.contains(description) || description.contains(searchParameter);

    }

'''

Same comment as before: we can consider moving the return statement into the catch block

Could we name this isCompleted to make it sound more boolean-ish?

Perhaps we can name this getTaskCount() to make the method name a verb

Could we make this a guard clause at the top of the method instead to make the happy path unindented and clearer?

Not sure what issues this might cause in the future, but it might be safer to set it as your actual package name in the future.

Since there are no classes inheriting from Event, should we set it to private first?

Same as above

Do you want to catch more specific exceptions? Might be better to catch a DateTimeParseException instead.

Might be worth using an enum for errorType, because it seems weird that you are comparing strings. Might lead to runtime improvements too.

Same as above, should use private

'''suggestion

    String dateTime = Parser.getDateTime(by);

'''

We should be consistent and use camelCase for our variables.

I feel the class name shouldn't sound imperative. Perhaps something like DukeFileReader (to prevent confusion with FileReader) would be better?

Might be better to wrap this into either a try-with-resources or try-catch-finally, so that the .close() will be run regardless of whether an exception occurs or not. In this case, when a IOException occurs in the previous lines, the bufferedReader.close() won't actually be executed.

Same as above

+1 on Jia Xin's suggestions. Method names should start with a imperative verb.

Same as above

Let's try to avoid unnecessary use of this (from advanced style guide)

Same, avoid unnecessary use of this

Hmm, you should look into this... Or just manually rename the folder in your file browser.

I like how you allow users to pass in a customisable filePath. Might be useful to extend functionality in the future / cater for cases where the user cannot write to the .jar file's directory (e.g. if the app is living on a network share with tight permissions).

Try not to use this unnecessarily. According to the advanced style guide,

Instead of specifically catching exceptions as part of your flow (in this case, to check if the file exists), we should manually refactor this part of the code to check for file existance, or even better, just use .getParentFile().mkdirs() and/or .createNewFile(), which are built in Java API methods that creates the files if they don't exist. Exceptions should be meant for error and ...exceptional cases.

Same as above. I think your code would look cleaner if you removed all unnecessary uses of this

Right now, I see many blocks of code where there is a huge list of exceptions to catch. Perhaps it's neater to refactor these exceptions to become a subclass of another Exception class? e.g. DukeException extends Exception, then make these extend DukeException. If the code is refactored that way, then you can just make use of substitutability and catch (DukeException e) instead of this long list.

Would be great if you could write more javadocs docstrings for public methods

Same as above

I feel this class name would sound better if it is made to sound less imperative, e.g. InfoParser

Might be better to use a method name with an imperative verb, e.g

'''suggestion

public void setTaskListDidUpdate() {

'''

Refactoring your exceptions in the way I mentioned above will also make your docstrings cleaner

'''suggestion

    // DONE PORTION HERE----------------------------------------------------------

'''

Comments should have a space after '//'

Should wrap this in a try-with-resources or try-catch-finally, so that we can ensure that .close() is always run, regardless of whether exceptions are thrown or not.

Currently, if an IOException occurs in writer.write, writer.close() is skipped, and this might cause data integrity issues.

Perhaps can split to multiple imports of duke classes?

Perhaps Ui class does not need to aware of the TaskList class?

Can consider Ui to display a message based on the provided arguments.

Perhaps can use List interface instead of ArrayList class?

So, it can accept different kinds of implementation of List interface.

Perhaps can abstract reading task from line to avoid duplicate check of task status and set the task as done?

Can consider creating a file if the file is not found in the load method.

Do check for the spelling of the method name.

Perhaps could handle the task message in each of the Task subclass?

For example, declaring a writeToFile method that returns a task message to be written to the file in the Task class.

Then, overriding the method in Todo, Deadline and Event.

Therefore, calling currentTask.writeToFile() will return the respective task message.

setIsDone and markAsDone have similar functionality.

Can consider combining these two methods and move the doneString to the relevant class.

Should Storage#createFile be called from the Storage#load method?

Should Storage#storeFile be called after every command to save the task message in case of the application crash?

Should there not be a space between the Javadoc comments and the override signature?

I like the use of enum here, make it easy to refer to the different types of command. 👍

Since this method covers a lot of logic, should it be abstract out to different method to improve the readability?

Can consider using try catch to handle the exception and display the error message?

Recommend to close the scanner to explicitly deallocate the resources.

Variable name must be in camelCase.

Perhaps can check if the new deadline task is added to the task list?

Can consider checking on the task list for other tests as well.

I mean can consider declaring ArrayList<Task> tasks as List<Task> tasks.

Oh, I see. Perhaps can consider rewriting the whole task information to the file after every add, edit and delete operation.

super() with no argument will be called implicitly. Can consider omitting the super() here and it applies to the rest of the Command subclasses as well.

Perhaps can throw a DukeException when the command is incomplete.

Can consider throwing a DukeException and using try-catch to handle it from the caller of AddDeadlineCommand#execute and it applies to the rest of the Command subclasses as well.

AddDeadlineCommand, AddEventCommand and AddTodoCommand are very similar. Perhaps can combine these 3 classes to AddTaskCommand.

System.exit(0) exits current program before returning ui.bye(). Can consider move the command after calling the ui.bye().

I like the exception handling of storage.load(). 👍

Is it required to declare an empty constructor?

I like the use of Constants.CommandType enum together with switch-case, it greatly improves the readability of the codes.

Is it required to declare List<Task>?

I like the test coverage of DukeException. Perhaps can further test if the DukeException display the respective error message.

Perhaps change the constants to all caps? e.g. BLANK, CLEAR, etc.

Might want to change the variable name to something clearer?

"done" seems like a boolean value, maybe try "isDone"?

Perhaps extract out certain parts into helper methods? Currently this method seems too long and will only grow longer as more logic is added.

Maybe split up this line as it is too long?

A single line main function! Nice 👍

Maybe remove the extra newline?

Perhaps extract the magic number into a constant variable?

Again, maybe consider breaking the method up into several smaller ones?

This code block is getting close to an arrowhead style! Maybe try to refrain nesting too many try blocks?

Parameters look quite long and there's many magic numbers, maybe split up the lines and use constants?

Perhaps change the method name to "printErrorMsg"?

Why does parsing "todo" and "event" expect an error command?

Perhaps a clearer variable name such as command?

A one line main function! Very nice 👍

Maybe change the comment to a Javadoc format for consistency?

Perhaps extract the code blocks within each if (t.isSomething()) out to separate functions? Otherwise as more task types add on, this method will get very long.

Maybe extract the magic number 7 out into a constant variable? Naming it would make what the 7 stands for clearer.

Nice breaking up the long line for clarity!

Maybe change the description to "prints goodbye text"? Currently the code block doesn't really exit the program.

Just a nitpick, maybe add a line break before the parameters?

Just a preference, but perhaps consider a switch?

I might be overlooking something, why is this a static method?

Again, might want to consider avoiding single letter variable names.

Perhaps consider grouping all static methods together?

Nitpicking, might want to add a period at the end and a newline?

Remember to add some unit testing!

Should this extra line break be here?

Shouldn't Task and the proceeding { afterwards be separated by a single space?

Perhaps the relevant io files could be listed and imported explicitly instead of using a wildcard import?

Perhaps Task and its proceeding { could have a space in between them?

For each line 7 and 12, shouldn't there be a space between the closing parenthesis ) and its proceeding brace {?

Shouldn't it be Runs instead of Run?

Perhaps you could import each class that you would require explicitly instead of using wildcard imports?

Perhaps there could be spaces between each expression and its operator?

For example, line 43 could be changed to:

'''

return (type.equals(command.type)) && (description.equals(command.description))

'''

Perhaps this line could start with * Contains information ...?

Perhaps you could import each class that you would require explicitly instead of using wildcard imports?

I noticed a similar issue regarding wildcard imports in several other places too.

I noticed a similar issue in several other places too.

Perhaps the extra line break could be removed here?

Is it necessary to import a class from the same package?

Perhaps you could do a line break before the operator, i.e.

'''

    this("java.tasks.Task not saved due to wrong format. ꉂ 'o´ ) Please specify the date in the following format: \n" 

            + "yyyy-mm-dd i.e. 2020-01-01");

'''

I noticed a similar issue in several other places as well.

Perhaps Cut could be changed to Cuts?

Maybe Return could be changed to Returns?

Perhaps this block of code could be abstracted into multiple method definitions within this class so as to shorten the method length?

I noticed a similar issue here in several other places as well.

I noticed a similar issue in the leading word of each Javadoc comment in other places as well.

Perhaps this could be renamed to getData()?

Maybe this single line break could be removed?

I noticed a similar issue wrt Javadoc comment leading words in several other places.

I noticed a similar issue elsewhere regarding Javadoc comments.

I noticed a similar issue with import wildcards in other places.

Perhaps you can use a noun and something less ambiguous for the method name such as taskFormatter()?

Be careful of white space requirements as mentioned by Jaylenlee

I am not too sure if the usage of while loop here is an acceptable standard, perhaps you can shift this to the top?

Maybe you can remove the extra line spacing here?

Is this necessary? Since the function does not need return anything.

Perhaps add a line spacing here?

Does this method require an @Override annotation?

Perhaps deadlineInput is clear enough?

Maybe use a more specific name instead of 'flag'?

Can you confirm if the order of import statements here are correct?

Maybe use a more specific name for the parameter 'bool'?

Maybe use 'numberOfTasks'?

Maybe use 'getNumberOfTasks'?

Maybe use a less ambiguous method name here?

Maybe 'deleteTask' will suffice?

Perhaps avoid naming variables like var1, var2 and so on? Try using a short form of the type of error such as 'accessError' or 'deleteError'?

The code for this class is clean and adheres to the Java coding standard as far as I can tell. Good job!

Is this line missing a semicolon?

Would 'time' be a better name for this variable?

Is this variable necessary? Perhaps you can just use the variable i in the for loop?

I like the fact that you abstracted these methods instead of writing everything under the parse method.

Perhaps use a more descriptive name for 's' like 'description'?

Maybe add a javadoc comment here? Even though it is just a getter.

I feel that this variable is slightly redundant? (Not sure if you want to keep it for the purpose of being clear)

Perhaps just "Deletes the task at the specified index." will suffice?

Maybe you can add javadoc comments for the public methods here?

Perhaps you can separate the tests and name your test methods in this format: featureUnderTest_testScenario_expectedBehavior().

You can refer to the naming conventions for tests here https://se-education.org/guides/conventions/java/index.html under the "Naming" section!

Maybe you can test the loading functionality and the Todo Class functionality separately? It might make more sense to test Todo functionality first in this case separately, then test the loading.

Perhaps you could add in an assert equals for testing purposes

Perhaps the user does not need to know about the file path validation process? I would suggest these be used more as debugging statements!

Perhaps here you could catch the FileNotFoundException and then throw a custom DukeException such that your Duke class can handle the thrown Exception, and you wont need to handle this specific Exception at all reducing the scope of Exceptions thrown!

Refer to the comment on the FileNotFoundException!

This is incorrect, the Parser class is used by the UI class.

Maybe this method can be made more modular? It seems that this one method seems to have a lot of functionality that can be broken down into several separate methods, which can be made private for this class if necesary.

For the load method, refer to the comment on the parse method from the Parse class. Making your method modular is also applicable here.

I think it's great that your UI text will have user friendly icons! However, I do suggest that since these are Magical Constants, perhaps they can be defines as top level class members as private and final using the appropriate Caps Lock separation instead of placing them in the middle of your code as this may confuse future reviewers!

Perhaps in this case the variable is not necessary to be used?

Its a good idea to have a class of Common methods that are used throughout your code! I think I may implement this in my future projects!

Refer to comment on CommonMethod, is also applicable here!

Perhaps you can think about shifting your taskList object to the StorageManager Class? Having your taskList in your main class could possibly complicate your manipulations of the items inside!

Perhaps you can catch the IOException error within the originating class and throw a DukeException instead, that way the main Duke Class never has to deal with Exceptions that are expose the Java Exceptions! Although it is always good to be explicit in what errors you are catching, since most of the originating errors are Extended from DukeException, you could always just use

'''suggestion

        } catch (DukeException e) {

            System.out.println(e);

        }

'''

Perhaps there can be a better way to Store your isExit variable instead of having to pass it in to every Command Object that is initialised, since not every Command Object needs to know of the existence of the isExit parameter, as can be seen from your AddCommand class constructor, where you initialise isExit with false.

As with the taskList being passed around the entire program, the uiManager and storageManager Object are being passed around the entire program, which may not be necessary. Consider using a Non-Persistent Storage Object at initialisation of program so that you can easily reference to the non persistent data throughout the program without using up parameter space to pass in objects that may or may not be used by the methods/classes that they are being passed into

Consider using in built Date and Time objects that are provided by the Java JDK! They provide extensive functionality including parsing and Formatting abilities!

Perhaps you can consider splitting this class into multiple classes, such as a Save and Load file which deals with persistent storage and consider having another class for Non-Persistent storage! Making your classes more modular will help you maintain your code in the future!

Refer to comment on IOException in the main Duke Class!

Perhaps instead of making this ArrayList Object into a class and only exposing the methods that are required, you can consider using a Storage class from which you can accomplish the same goal but have the flexibility of having more methods related to storage rather than restrict yourself to methods only relating to one specific data structure!

I like this class because its function has been very well defined and followed through with! Good job! 👍

Perhaps you can consider another case - what happens if a user types in a command with the wrong capitalisation? Does your program still accept that as the correct command?

Its good that your UI has such a User friendly display! Maybe you can instead define these as private final constant variables above as class level members since these look like Magic Numbers that may confuse future reviewers!

This seems like a common method for DeadlineTask and EventTask, is there a better place that you could place this method?

You seem to have done extensive testing! Good job! 👍

Perhaps add this file to .gitignore?

Perhaps use respond() instead? The coding standard states "Names representing methods must be verbs".

Should there be a period at the end of this line?

Similar to the issue in Bye.java, consider respond() instead?

Consider abstracting this logic somewhere else since this method is getting rather long?

Consider respond() as above?

Should there be whitespace between ')' and '{'?

Should the indentation for wrapped lines be only 8 spaces?

Consider adding a verb to your method name? Maybe printListOfTasks()? The coding standard states "Names representing methods must be verbs" and that would be more intuitive for the reader as well.

Should there be a Javadoc comment for this public method? Unclear what this method does. Consider adding a verb to the method name as well?

Perhaps there is no need to split this into 2 lines? May be easier for the reader to read that way.

Consider abstracting some logic away? The else block seems to be getting long.

Perhaps use a clearer class name? Some readers may not know what 'ls' is.

Should this be a multi-line comment instead? The coding standard only states "Javadoc of class members can be specified on a single line". However, since this comment is for a class, perhaps it should follow the general form for Javadoc comments where "The opening /** [is] on a separate line"?

Should there be a period at the end of this line?

Should there be periods at the end of each of these lines? The coding standard states "Punctuation behind each parameter description".

Should this be a multi-line comment instead? See similar comment in Deadline.java.

Should this be a multi-line comment instead?

Should there be periods at the end of each of these lines?

Same issue as above

Same issue regarding single line comments as above. Perhaps check through the rest of your classes for this issue as well as the issue regarding the periods at the end of lines?

Agree, the rest of your classes seem to use SAVE_PATH as well. Perhaps this is an oversight?

Agree, the coding standard states "there is no indentation for case clauses."

Agree, the coding standard states "Names representing methods must be verbs".

Is it better to specify the visibility of the constructor, e.g. public?

Maybe add JavaDoc for this public class can make your program clearer?

Do you expect this method to have a specified visibility, e.g. public? I will omit similar problems of missing specification of visibility for other files.

Since you name this as an exception, do you intend to make this class an exception? So perhaps extend the Exception class? EventException and ToDoException also has the problem.

What is this exception? When would it be thrown? Perhaps it is better to specify in the JavaDoc. Same for other JavaDoc comments for @throws tag.

What does the return value mean for create()? May specify it? Same for some other JavaDoc on methods.

Is this a typo? Do you mean Getter for the arr? In addition, for the JavaDoc description of a method, you may start using a verb. So maybe it'll be better to say something like Gets the arr.?

Would it be better if you use more meaningful names instead of abbreviation?

Perhaps here should be a tag @throws for the JavaDoc of this method? I observed similar problems with some other methods as well.

Perhaps a new line before the main method?

Maybe you can add a JavaDoc for this class?

Would it be better if you name these 2 variables like indexOfSpace/Slash or positionOfSpace/Slash? Although I can understand what you mean, and it causes no confusion in this context, the meaning of the variables seem a bit ambiguous.

Maybe you can add JavaDoc here since the overridden method also has no JavaDoc? Same for a few other Command classes.

private int index;?

Same as DeleteCommand. Maybe you mean private?

Did you accidentally add an extra space after before extends?

In addition, IncorrectFormat seem not to be the conventional way of naming an exception. Perhaps IncorrectFormatException? Or maybe even more specific.

Furthermore, maybe add a JavaDoc for the exception would be better because IncorrectFormat is still vague and ambiguous

Similar to your IncorrectFormat about the naming.

Did you make a typo here? Do you mean Processes ... and returns ...?

Typo here? The instead of THe.

Is IOException really thrown? I think you've dealt with it using catch right?

Similar to createFile method about the IOException.

Set it as private?

Maybe a more meaningful name could be better?

May specify all as private? I will omit other similar problems from this point.

Is the last space before ) extra?

Consider a more meaningful name? (By the way, is this variable used?)

I think it is better to explicitly state the imported classes that you're going to use instead of using '*' 😄

I think it complies with the coding standard more if you add "// Fallthrough" at the end of each cases with no "break" line.

LGTM 😄 I like the clean coding style.

I like how you use switch statements 😄 It's easier to read compared to 'ifs and elses'.

I think it's better to omit the default if it contains no statements, it makes the code simpler.

Perhaps you could use a StringBuilder instead? I think it makes it run faster. It's optional though 😅

LGTM 😄 Other than a few small (optional) changes.

I like the clean coding style 😄 LGTM!

I think attributes should be private (and if used outside the class, try adding a get method)... Noticed it, in other Command classes as well. I like how you're using it to improve code readability 😄 Other than that, LGTM!

You can omit this 😄 I think Java has automatically built an empty constructor method for every object... Noticed it in other types of commands as well.

It's cute, I love it! 🥰 LGTM!

Perhaps you could add a blank space to separate import statements from different packages? I think it complies better with the CS2103 coding standard 😄 Noticed it in other classes as well.

I like how you specified the correct format! It lessens the confusion for new (possible) users! 😄

I noticed you haven't added Javadoc to any of the classes and methods 😅 Perhaps you could add it in the future?

I think it complies better with the Java coding standard to put the square brackets '[ ]' next to the data type 😅 Noticed it in other places as well.

Since this statement is used in most cases, perhaps it would be better if you move the code above the switch statements (use it more globally?) and add an exclusion for cases "list" and "find" 😅

Perhaps it would be better if you moved this method to each of the Task classes and use polymorphism to your advantage 😅 It makes it more simpler and logical, I think.

I think it's more efficient if you put the message in the exception's constructor instead so you don't have to type it for every case 😄 Noticed it in other exceptions as well!

I don't think this if statement is necessary since Java already has an IndexOutOfBoundsException, perhaps you could throw the InvalidIndexException when catching that instead? 😄 Noticed it in other methods as well.

Perhaps it would be better that the attributes be made not public? 😅 I think it complies better with the coding standard set by the module. Noticed it in other classes as well.

I think it is better to make an attribute for isExit, hence there is no need to type multiple isExit methods for each Command class. You can just make the isExit method return the value of the boolean attribute in the Command class 😄

Perhaps it would be better to make a new type of exception (extending DukeException) for this type of error 😄

I think it's better to rename the method to "getCompletionStatus" or "getStatus" or something similar since it (grammatically) makes more sense 😅

I like how you followed the naming method for testcases! 👍

Since the coding standard demands use of US English, I think it's better to rename it to "initialize" 😅 Just a small (optional) change though, otherwise LGTM!

consider adding a whitespace between Command and { for readability

Would be nice to add a javadoc comment for readability

Should the block comment be at this level?

Consider adding a javadoc comment here too

Having a javadoc comment here would be great for readability

Consider having a javadoc comment here to help readers

There's a hard to catch trailing whitespace after EventException,

1 extra whitespace between super.toString() + and " (at: " that you might have missed

trailing whitespaces here as well

some trailing whitespaces here

Should the imports be in this order?

There's some trailing whitespaces you might have missed on lines above and below generateSaveFileData();

this method might do well with accompanying javadocs

consider not sandwiching every method here with whitespaces to help prevent diff noise

should letter be public?

should static modifier come after final?

should "+" be on the old line?

should "?" and ":" be in a staircase format?

you missed a ; here

Consider the class name CommandDeleter as it is a noun

Should the class name be a verb? Pardon my naming sense, but do consider something like DoneMarker

Consider using a noun for class name

Consider using a noun, like CommandLister

the name "of" is slightly ambiguous, might I suggest something like parseTime?

Perhaps it may be better to list the imported classes explicitly so that others can easily identify what classes are used?

Maybe we could standardize the use of this keyword as these statements imply there's another ui/parser object?

I'm not really sure, but since this is a public method, it may require a javadoc?

Quite minor, but it may be clearer to state that this function will mark the task as completed since it's not possible to mark it as incomplete.

I think there's no need to override the inherited function if there's no change made to it?

I really like how you separated the emojis out into an enum!

Maybe you could extract out the command name by splitting the string which can also help with the condition checking?

In Javadoc comments, there should be an empty line between description and parameter section and the first word of the params' description should be capitalised.

In Javadoc comments, there should be an empty line between description and return section.

According to Java guidelines, this should be "represents".

According to Java guidelines, this should be "constructs".

According to Java guidelines, this should be "constructs". There should also be an empty line between the description and params here, and the first letter of the params should be capitalised.

(There are more Javadoc comments that require a little editing, but I will stop adding more comments here so as to not flood the reviews!)

I think this new line isn't necessary, so maybe it can be deleted?

Perhaps you can throw a child of DukeException here to tell the user that they may have forgotten to input the number of the task to be marked done for better UI.

Perhaps you can throw a child of DukeException here to tell the user that they forgot to input the number of the task to be deleted for better UI.

As it is possible to initialise the taskList without a defined capacity, would it be better to just leave it undefined so that there is no limit to the number of tasks that will be added in?

Similarly, perhaps throwing a more specific Exception here may be better to inform the user they failed to give the correct task number to be marked as done.

Maybe the message here ("The description cannot be empty") can be encapsulated in DukeNoDescriptionException instead, so you don't have to throw a new Exception.

Similarly, maybe the message can be encapsulated in DukeNoDateException to reduce the number of try/catch blocks.

I think this can be generalised to DukeException?

I think this empty line is not really necessary, so maybe it can be deleted?

Since it is common to leave out a return statement, maybe the //Fallthrough comments could be added here to show that it is intentional?

Unnecessary empty line, maybe it can be deleted?

I really like how you separated this out!

Since an object of Command class would unlikely be instantiated, I believe it would be better if it was made abstract instead. This is similar to cases where the Animal and Shape classes are made abstract etc.
I noticed that you did not put access modifiers to tasklist and str. It would be good practice to make them protected variables since they are inherited from Command subclasses.
tasklist may not be needed as an attribute here, and can instead be used simply as an attribute in the execute() method.

Also, I notice that you have missing JavaDocs for your classes themselves; please do add them by next week's increment to adhere by the coding standard!

It may not be obvious at once to those reading/testing your code as to what an exceptionCommand actually is; perhaps a more intuitive approach would be to check if the input is valid while parsing and output the exception from there, instead of having to create a new exception command.

To adhere to the coding standard, this import statement should be grouped above with all the import.java statements above.

These import javafx statements should be grouped together with those below!

DialogBox feels like it could be placed in a separate class by itself. It may confuse readers/testers when the first class they see in Duke.java is the DialogBox class instead of the Duke class!

A more appropriate option would be to make the first letter of a class name uppercase in adherence to the coding standard. Similar mistakes are found in the following classes as well. camelCase should be used for variable and method naming!

Minor issue, but this file can be removed if it is now obsolete.

To rephrase, it would be better to group this exception with your DukeException class below.

A space should be needed here to separate the 2 import statements.

One neater alternative would be to make smaller methods such as handleDeadline() or handleEvent() for example instead of one huge method which handles every case bulked together. This could make the code appear untidy and bulky.

Instead of using the wildcard(*), do list out all the import statements used from the java.io package.

It is important to ensure that your class attributes are labelled as private. I also noticed some other attributes in other classes without access modifiers or having the wrong ones attached to them. Do take note of this!

Instead of suppressing it, maybe you could try resolving this warning such that it does not pop up again. This statement would be redundant if this warning can be resolved manually.

The indentation here looks inaccurate. The first line of the String should follow the return statement above instead of being below it and indented again.

It is good that you considered creating a pleasant user experience by making it easier for users to enter correct commands!

I like how you used an abstract method to account for program exit for all Command subclasses. One other cleaner way could perhaps be to make the method simply return a boolean value which would eliminate the need to create an isExit attribute.

It is great that you created a custom Date and Timing class to format your date printing, but perhaps you would have had your work cut out for you if you had used the Java Date library instead! They have methods to print your dates and times in different formats too.

As you have multiple Deadline constructors, I think it would be great if you commented on what each of them did differently and how the extra parameters influence how the object is instantiated.

It would be better to adhere to the coding standard and make the attributes private here instead!

This may not be required since the Exception class has its own String attribute called message as well as a method for its subclasses to retrieve the message.

A similar issue to the Deadline constructors I commented on a while back. It would be great if your comments could be more detailed and diverse for constructors of the same class!

This method is a little long. Perhaps you could consider making smaller methods such as handleDeadline() or handleTodo() for example to make the code cleaner and more organised.

I like the simplicity and structure of this enum, which is set up such that it is easy to add more new TaskTypes in the future if needed.

I think the ordering of the imports are not correct? 🤔

Should there be a new line after the description, to separate the description and parameter sections?

Maybe you could take a look at Duke.java? It is the same issue, and for the rest of the classes too! 😅

I think the naming for exit variable could be clearer and sound more like a boolean, so maybe you could consider isExit? Just a suggestion!

Should there be a description for this method in the Javadocs? 🤔 Maybe you could also check for subsequent classes too (i.e. Parser.java)!

Maybe a more intuitive variable name called index would be clearer?

Maybe you could look at DeleteCommand.java? It is the same issue. 😀 You could also check for subsequent classes too (i.e. Parser.java).

Maybe a clearer naming would be getTask(int index)?

I like how you have variations for users to input their Deadline and Event tasks! 👍

Maybe you can consider naming this method as formatTaskToText()? Just a suggestion! 😃

Maybe you could create a method in Task.java which returns the tick or cross symbols based on whether the Task is done? This might reduce the duplicate codes in the 3 different types of Task classes! 🤔

Should there be a spacing after Exception followed by the starting curly brace? 😀

'''suggestion

public class DukeException extends Exception {

'''

Maybe you can take a look at DukeException.java? It is the same issue. 😅

Maybe you could take a look at the suggestion mentioned in Deadline.java? Same for ToDo.java!

I am not sure about this, but I think there should be a spacing between closing parenthesis and starting curly brace?

'''suggestion

protected Parser() {}

'''

Should there be a spacing between these imports? 🤔

Should there be a @return for the boolean in the Javadocs? 😅

Maybe you could look at Storage.java? It has the same issue.

I think there is an extra 4 spaces for the indentation?

Maybe you could take a look at the above comment? It is the same. 😃

I like how your bot is personalised! 👍

Static imports should have precedence, followed by Java's imports, then followed by this Test import. Maybe when you run checkstyle, you would be clearer. At first, I did not know too! 😄

'''suggestion

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.time.LocalDate;

import org.junit.jupiter.api.Test;

'''

Maybe you could take a look at ParserTest.java? It has the same issue, and for the rest of the test classes too!

I like how comprehensive your testing is! 👏

May you could rename the method to getMessage for better clarity?

Perhaps you can organise your code into packages for better modularity?

Perhaps you can rename lists to taskList, since it is supposed to be singular? Additionally, taskList can be declared as List instead of ArrayList.

Can consider using a switch statement for better readability.

Perhaps this line is redundant?

Nice customised design of duke 👍

Should you refactor into 2 variables instead?

Maybe you could consider using just a string to store one String?

Perhaps you can print out the response message to the user on line 86 like u did for line 83?

Should there be nested try and catch?

Can consider printing a message to the user instead of using the default constructor.

You may consider adding a custom message which is easier for user to understand.

Eg.

'''

public DukeException(String message) {

super(message);

}

'''

Perhaps you can refactor this method to the Task class to avoid repetition of code in child classes?

Should your exceptions in your programme extend Exception or Duke Exception?

Perhaps you can rename Tag as CommandType for better readability?

Should the variables be public or private?

Consider renaming linesOfText to responseText for better understanding.

Should the indentation be at 8 lines instead of 4?

Nice use of javadocs to credit the original author 👍

Perhaps using else if will make the code look nicer?

Will it be easier to read if the ToDo class is renamed to Todo?

Consider renaming the field by for easier understanding

nice use of method to extract out the status icon

Consider ending the summary sentence with a period?

Javadoc requires that the first sentence ends with a period. https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html

Consider removing the whitespace between the method name and parameters?

Same on line 66.

This is slightly over 110 characters. Since it's already being wrapped from Line 54 maybe you could wrap it again to another line?

Consider specifying under what conditions the exception is thrown?

If an exception is caught and you weren't expecting it, will this cause the test to pass mistakenly? You might want to check that out.

If this file is to store user-specific data, perhaps you can add this to .gitignore instead?

Can the magic number be converted to a more meaningful value? (e.g. "/on ".length())

Would input.startsWith("deadline ") be more readable instead?

Would it be more readable to use streams here instead?

'''java

return IntStream.range(0, tasks.size())

            .mapToObj(i -> String.format("%d. %s", i + 1, tasks.get(i)))

            .collect(Collectors.joining("\n")) + "\n";

'''

This is very similar to printList() and might be a violation of the DRY principle. Could the common logic be extracted to a helper function instead?

Or perhaps printList() could just call printList(x -> true).

Is this file being used for testing, etc.? If it's just to represent the user's individual saved data then would it be better to add this to .gitignore?

There are two main methods - one here and one in Launcher.java. Which one should I be looking at?

Perhaps you could remove one of them if it is no longer needed to avoid confusion. Remember to update build.gradle as well.

I think the opening /** should be on a line of its own, with the summary statement on the next line?

I think this line may need to be indented one more level?

taskDeleted may be slightly misleading as the task is not actually deleted prior to calling execute. Perhaps the parameter can just be named taskIndex? (same as the attribute name)

Completely optional stuff here but I would love to see streams being used for this purpose. Something along the lines of

'''java

matchedTasks = taskList.getTasks().stream()

        .filter(this::matchesAllWords)

        .collect(Collectors.toList());

'''

Does this necessarily need to take in an ArrayList specifically? Perhaps it could just be a List instead?

Similar suggestion for streams here.

'''java

return Arrays.stream(searchWords)

        .allMatch(word -> task.getDescription().contains(word));

'''

A List has an isEmpty() predicate. Should that be used instead?

An if-else block for every type of task with a date may become unsustainable in the long run if more task types are added. A suggestion (off the top of my head):

Create an interface TimeBased (name is up to you) with a single abstract method getTime(). Tasks with dates associated (Event, Deadline) can implement TimeBased based on their own getAt or getBy.

Then in cases like this, we can just use task instanceof TimeBased and getTime here.

Would that improve the code?

Should this be final as well since it's a constant?

Should there be a space between 'run' and '{'?

I think the imported classes should be listed explicitly? (Instead of using *)

Should there be an indentation for case clauses in a switch statement?

Should this class field be left with the default access modifier?

Should there be no empty line between the Javadoc comment description and parameter section? I've noticed this issue in other Javadoc comments as well.

Should there be no spacing between 'Command' and '{'?

Should the import statements be more consistent in format? I.e. New line between duke imports and standard java imports, just like in the other files.

Should these variables be left as the default access modifier?

Should this if statement be on a single line without curly braces?

Should the case clauses have indentation?

Should this if statement be on a single line with no curly braces?

Yup, but its indented in your code haha 😅

Should there be a space between 'run' and '{'?

Perhaps this can be renamed to 'arrayContainsString'. Also, seems weird to put this in a Parser class, perhaps a separate utility class can be created instead, especially since this method doesn't use any of the instance level variables.

I think it would be clearer and more direct if inputString is used instead of getString() as readers may have to check the getString() function to see what it does, instead of directly seeing that it is just returns the inputString variable.

Perhaps this function should be renamed to getInputString() to be clearer and more direct about what it does.

Should there be a new line before this Javadoc comment?

Perhaps this variable can be renamed to userInputSplit as userStrings sounds a bit unclear and vague.

Should there be a space between // and the comment contents?

Should the getArray() function name be changed to something more descriptive? For example, getUserInputSplit()

Perhaps the name of this function should be changed to something more meaningful? What is the significance of the first index?

Should the boolean be named isDone instead?

I feel that a better name for this function would be something like getStringForStorage(), because appendFile doesn't seem to describe what this function does well.

Should this be listed explicitly?

Should the import statements be listed explicitly?

Should there be empty line between description and parameter section?

I liked how detailed this java doc is

It is good that this did not take up more than 3 indentation

Does this need to be public?

Why does this overloaded method needs to be public if it's only used inside this class ?

I like how this is abstracted and kept inside this class

Does this need a @Override tag?

Is this merge conflict resolved?

I like how descriptions is given for these private variables as well

I liked how enum is used for these commands

I noticed a lot of your methods are marked as package private, why don't mark them as protected instead?

Could this method name be matched closer to what it does?

why is this not called after the constructor instead of calling it in duke.java?

Maybe this can be placed inside DoneCommand?

It's nice you separated out this exception instead of also classifying empty input as a DukeException

Is this a bit unnecessary because the variable date is self explanatory

Maybe the head comments can be shrunk to one line?

This would make the code look more compact and neater if the header comment is not too long.

I noticed there were some quite short comments which could have been shorten to one line

/** The Todo, ... to it. */

It is good that you have so many test cases, this shows that you test your codes thoroughly 😃

Maybe this code is self-explanatory? There were also many instances which I feel that the variable name is self-explanatory.

Maybe this does not need a comment header?

Is the "this" keyword necessary?

Are the "this" keywords necessary?

Is the "this" keyword necessary?

Are the "this" keywords necessary?

Is the "this" keyword necessary?

I like the lexicographic way in which you arrange your import statements in all your classes, perhaps a line break between lines 4 and 5 and lines 5 and 6 would make the import statements look neater? 🤔

Perhaps a line break between lines 5 and 6 and lines 6 and 7 would make the import statements look neater? 😄

Perhaps a line break between lines 6 and 7 would make the import statements look neater? 😄

Is the "this" keyword necessary?

I like the lexicographic way in which you arrange your import statements in all your classes, maybe it will look neater if there is a line break in between the the import statements at line 4 and 5?

Also a swap in lines 3 and 4 to make it look consistent. 😄

non-private variables should be declared before private ones right?

I think there should be a space after Task

I think there should be a Javadoc comment here!

Should the indentation of "case" same as "switch"?

This import is unused and should be deleted right?

the trailing "+" sign should be on the line below right?

Should there be a Javadoc comment here?

Should filePath be private and have an accessor method?

Should the data file be ignored?

Perhaps this part should use switch case? And also for the todo/deadline/event, I think you can use String format to reduce the number of duplicate code

Maybe change the name here from splits to tokens?

I think the method name should be a verb, so maybe change exists() to checkExist instead?

If there is an exception here, should the program be ended?

Maybe if you write return above then no need this else? To keep the "HAPPY" path straight?

Perhaps the two function should be merged into one to reduce duplicate codes?

I think the name of the taskList should be changed since it can be mistaken with tasks!

I think the 2 if should be merged together!

I think function names should be in verb-form

A very small thing but I think you may find useful that the size of the array cannot be negative, so I think just check if it's equal to 0 or not is enough! A better way is to check task.isEmpty()==true

I think the horizontal line should be a static variable and should only be created once

I think the name line can be more descriptive!

I agree. Maybe Egyptian style bracketing should be used?

Should there be a break statement after each case?

Should import statements here be stated explicitly?

Should complicated statements be avoided? Maybe you can try to have it done in steps?

Should the form of the try-catch statement be changed?

Should naming be changed to a verb instead?

Should naming be more accurate in explanation about the method?

Should the naming of boolean variables be in another form such as isSomething or hasSomething?

Should imported classes from the command package be listed explicitly?

Similar to the above, should imported classes from the task package be listed explicitly?

Should there be a line break for this long line to improve readability?

Similar to the above, should there be a line break for this long line?

For the method body, should there be blank line separations between logical units within a block?

Should this variable name be in camelCase instead?

Should the javadoc comment header be more descriptive as the method is pretty long?

Should the method definition have an access modifier?

Should the method definition have an access modifier? This is also seen in a few other instances in the code.

Should there be a javadoc statement for this public method?

Should there be a javadoc comment for this public method? This is also seen in other instances in the code.

Should plural form be use for the name here as it is representing a collection of objects?

Should plural form be use for the name here which represents a collection of objects?

Should import statements here be listed explicitly?

Perhaps you can change the name "by" to something that is easier to understand? For instance deadlineDate or ddlDate or just date?

Perhaps can change the name "at" to something more comprehensive

Wow. I learn a new way to read files today. Thank you

Perhaps you want to leave a line to separate javadoc description and @param

same i agree 😃

great use of enum. Very clear of the possible tasks

perhaps you want to use the name index instead of idx to improve comprehensiveness

Wow i learn something new today that javadoc can inherit too. Thank you

it will be better to add an empty line between the javadoc description and @param

Perhaps you want to leave a line here as well

Perhaps you want to leave a line here to separate description and param as well

Start the javadoc with Executes (verb with s)

In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)

Similar as previous comments. Perhaps you want to refine you javadoc abit.

perhaps the word input here should be moved up?

Perhaps you want to leave a line here between description and @return

Yep, i noticed this in several other JavaDoc comments as well.

I like how neat this code is 😃

I am not so sure what this JavaDoc comment is referring to?

I think this is redundant in default as '//Fallthrough' is generally only added when there is a case statement without break.

Maybe it's better to throw a DukeException here instead of returning a String? I've noticed this method implementation differs from other Command classes, is there any reason why?

Perhaps return type should be void rather than String? As if I didn't miss anything, the returned string was not used in any of the references.

It may be better to specify more clearly what each execute method does for better understanding of the code? I noticed this applies to other Command classes as well.

Yes! Good catch. That would also improve the clarity of code 😃

I think it is better to standardise the format of DukeException? I've noticed the DukeExceptions thrown in Command classes did not have the sad faces. Perhaps you can abstract ' ☹ OOPS!!!' out into DukeException itself so you don't have to type it repetitively throughout your code?

I like how you specified the recommended date time input format to the user! 😄

Good work in separating the import packages for better readability 😃

You may want to use String.format for clearer concatenation of strings 😃 just a suggestion.

I like how you used the appropriate access modifier 👍

I also liked how you use the appropriate singular and plural nouns in naming your variables 😄

I noticed you've hardcoded a lot of indentations to format the displays in your print messages, perhaps these could be abstracted out into a printMessage method in Ui that auto appends message to the spaces?

I think it complies with the coding standards better if you write 'Returns' (third person singular tense of the word for header) instead of 'Return'? I noticed the same issue in several other places of documentation too.

I like how you added comments to make the code more understandable 😄

Perhaps it would be better to standardise the exception message output by DukeException? So that you don't have to type 'OOPS!!!' repetitively in the code. I noticed this was different from the other error messages.

I agree, using constant variables to store "todo", "deadline" and "event" is a good idea! It could also be expanded to other command words like "bye", "help", "find"... in the previous lines.

Similarly, I think it would be better to write "Greets the user" for proper javaDoc.

This would definitely improve the abstraction! Perhaps the method could be used to print a message within the 2 borders? something like border + message + border.

I like how you added JavaDoc comments in every public method 😃 makes for very comprehensive code.

java import before duke import

java imported before duke import

Only collections have plural names

static import should be at the top

static import -> java import -> duke import

Maybe can put checkCommand instead, like standardizing the verb first or vice versa

Imported classes should be listed explicitly. Maybe you can change the IntelliJ setting, to only output * if more than 100 from same import, as I know IntelliJ will do this at times even if it is unchecked in the setting.

Might be able to standardize with the rest of your method

might create mistake between tasks and task if not careful

I agree with shermz-lim, try to configure your IntelliJ so that it will remove this problem going forward

Maybe can include the expected result in the method name

Missing @Override, your other task subclass have.

maybe can rename it, like initAttributeList() or something

same as above, more suggestion like createAttributeList(), not sure of the functionality of this method.

maybe don't use the default accessor type

same as above, maybe dont use default accessor type

same as above, try not to use default accessor type

Remember if you are changing to switch case. There is no indentation for the case word.

Different package, so it can remain this way unless u changing task.Task to be in the same package as duke

Maybe can remove this white space for standardization

What do you think about renaming "by" to "deadline" to make it clearer?

I think you forgot to add full stops here?😅 I noticed this for other Javadoc comments too

Perhaps it would be better to rename "at" to something more intuitive?

NIT: Did you forgot to add an "and" before "Updates.."?

I noticed that the try-catch block is being duplicated in quite a few cases. Perhaps you can consider moving the moving the try-catch block one level up, putting the switch case in the try block and catch DukeException?

Nit: I think JavaDoc comments starts with "Returns" instead of "Return"

Should the method be renamed to getTaskType to make it clearer?

Perhaps you can consider adding an @Override to show that this method overrides getType() in Task?

I noticed this is duplicated in quite a few methods. Should this be extracted out?

Nit: missing fullstop here

Nit: I think the JavaDoc comment should start with "Allows" instead of "Allow" based on the Java coding standard

I think you may have forgotten to add a full stop here😅

Nit: I think the JavaDoc should start with "Boolean" instead of "boolean"

Perhaps you have forgotten to remove the extra spacing before "Invalid"?😅 i noticed this in other uses of DukeException as well

Perhaps it would be good to explain when DukeException is thrown? E.g. when index >= 0... I noticed this in for other JavaDoc comments as well

Perhaps it would be better to rename size to something more intuitive such as taskIndex ?

Perhaps you have forgotten to include comment for DukeException, @throws ... ?

Any reason why this is outside of the switch block instead of handling it in a similar way like list on line 45?

I don't think this method is necessary since the method is not exactly overridden then you return super.getMessage()? 😅

Should "abstract" be removed from the JavaDoc comment since Task is not an abstract class?

Perhaps it would be better to change this to a verb instead such as markComplete to adhere to coding standard?

Perhaps it would be good to follow the naming for test methods in the Java Coding standards, featureUnderTest_testScenario_expectedBehavior()? I noticed this for other test methods as well!

Should you add documents for this class?

Should you add a period at the end?

Should you add a period at the end of this line?

Maybe you forget to change this documentation?

Should you add punctuations behind each line?

I noticed the same issue in several other places too

Maybe can write a more meaningful description for the param?

I think there should be an empty line between description and params

I feel that a more meaningful name can be used instead of "I".

Is this line a bit too long?

Maybe the description can be more meaningful?

Since you have already had a getter method for description, maybe you can make it a private variable here? If you want to also modify it, I think a setter method may be helpful.

Maybe you can add documentation here and for the method below?

Maybe you can use a switch statement to make it cleaner?

Maybe give it a more intuitive name?

Maybe you can separate this into another catch block?

Maybe you do not need the "else if". Just use "if" to make the "happy path" more prominent.

Similarly, maybe you can consider removing the "else" to make the "happy path" more prominent.

I think it might be good to use the same abstraction level. So maybe you can create a new Event variable for this?

Maybe you can abstract out the "Bye bye..." string to enforce the same level of abstraction.

Maybe the name for the Command can be more meaningful?

I think ierateAndPrintTodo might be a name that better captures the purpose of this method.

Should these be declared as private?

Perhaps declare the conditional statement outside to make it more easily readable? Like boolean input = ui.readInput().equals(BYE)

Should all these functionality be abstracted out into another class so the code here isn't too long, like the Parser class? I like your usage of switch instead of if-else though

Should the printing of these statements be abstracted out to the UI class?

Perhaps you could abstract this out into a toString() method for your TaskList class instead?

I like your usage of streams here!

Should these be declared as private instead?

I'm quite confused about why you have both a TaskList task and a Tasks class

Should these methods be renamed to be more intuitive? Like showDoneTask() or printDoneTask() instead

Maybe declare this as private as well?

Should this be declared private as well?

Perhaps shift the "finally" to be on line 297?

I think you misspelled find in the error message

Perhaps you could rename the method to fit the coding standard? Like "printFileError()" or something similar

Perhaps you could initialise i here together with the declaration instead of within the try block?

Perhaps you could declare this to be a private variable?

Perhaps declare this as a private variable?

Same as Event and Deadline

Perhaps declare parser to be private instead?

Maybe you could rename this to avoid confusion with the actual variable? Like "getExit()" instead

nice logo!

Same as others, maybe change these to be private?

Just a minor code styling issue, no indentations are needed for the different case clauses.

Minor coding style issue, think that there should be a line break between the description and @param (according to the code snippet in the java coding standard). Noticed these java doc formatting issue elsewhere as well.

Can consider adding the "No such command" string in the exception constructor so that the user knows why his command was not accepted like what you have done in the parseTask method.

I think there is a missing java doc for the class itself. Noticed this in some other classes as well.

This works perfectly fine but can consider using the enum.valueOf method provided by java. In that way you don't have to declare the constants above and can use switch case instead of multiple if else statements when parsing the command. You also wont have to call the .equals string comparison method in every if clause.

I think the line break is not needed here.

I think this line break can be removed?

Can consider declaring a constant where such as done = "1" means to improve readability when creating new tasks. (This way the reader knows 1 is not just a magic number).

I think that according to the coding standard booleans should be named more obviously so done can be isDone.

Agreed, even though the scope is small it might be clearer to use a more descriptive variable name. Looking at your takeInputAndReturn method maybe x can be renamed to commandStatus?

Can consider being replacing "if something goes wrong" in the javadoc to some thing more specific. I'm not sure what because I haven't done the java FX portion but if its meant to be generic then its fine!

I feel the comments might help make things clearer especially for readers who are new to javaFX.

Can consider writing java docs for these methods (even though its trivial) because based on the coding standards all public class and methods should have headers. I noticed the same issue with some of the other public classes as well.

Agreed, no indentation needed for case clauses. To add on, I think there isn't supposed to be a line break between cases as well (referring to the code snippet in the coding standards) but i'm not sure if that must be followed strictly.

Can consider removing the line breaks in the catch blocks as the code snippet in the coding standards for try-catch statements don't have the line breaks.

Should the line breaks in the variable declarations here be removed?

I think a brief description for each method is needed at the start of the javadocs (before @param, @return, @throws)

Think you might have missed out javadocs for the class itself.

Think the imports should be specified instead of using *

Agreed, unless the character line limit is reached.

Maybe these comments can be removed? Unless its still needed for reference.

Should there be javaDoc comments for the methods?

Should there be javadoc comments?

Should import java.io.* be used?

Perhaps use a method that helps you indent all System.out.print lines

perhaps use a better name than "fnfe"

Perhaps have a method to help you add indention to all System.out.println() lines

i like the use of the override .toString() to format the time

Perhaps use key switch style

Why is the code so perfect its really tough to find coding standard violations only

should this line be this long?

Perhaps it should be "Edits"

Perhaps use "Deletes" instead?

Perhaps use "Updates" instead

Perhaps use "Returns" instead

Perhaps use "Removes" instead

perhaps use "Finds" and remove the

perhaps use "Returns" instead?

Should you update the text to comment what the method does?

Should there be a javadoc comment here?

Should it be "Returns" instead?

Is it necessary to leave a blank line here?

Would it be better if you just use an enum class for COMMAND_TYPE?

Correct indentation for switch method which is a common mistake, good job 👍

Would it be better to remove these empty lines before the brackets?

You may adjust the indentation for switch method as there should not be any indentation between switch and case according to the guideline 😃

I suppose this class exists for the conversion between different DateTime format. You may want to check on the existing functions in Java to do this: https://stackoverflow.com/questions/3469507/how-can-i-change-the-date-format-in-java

Is it necessary to leave empty lines here?

Would it be easier if you just create an enum class for COMMAND_TYPE instead?

Should "isExit" be "hasExit" instead? Perhaps it will sound more natural and grammatically correct if you intend for it to represent the state of Duke 😃

Should it be named "getExitStatus()" instead of "isExit()" ? The action of retrieving exit status may be more explicit this way 😃

Could you think of more specific and descriptive names for your variables? "str", "temp" and "current" may be vague at the first glance 😃

Correct indentation for switch method, this is a common mistake. Good job 👍 !

Should you remove this empty line between class header comment and the class itself?

Is there a better way to structure these to extract common code and reduce duplicates?

Would it be better to change "isExit" to "hasExit" to make it more natural?

May I ask why this must be a method instead of a boolean attribute?

Would it be better to name it more specifically, e.g. "listOutTasks" instead of "execute" ?

May I ask why you leave line breaks for each if/ else if statement? Is the line breaks necessary?

I like it that you put the details in comments! It makes your codes more readable 👍

Is there a more elegant way to do this? You may want to check on this link for more information 😃 https://stackoverflow.com/questions/3469507/how-can-i-change-the-date-format-in-java

"isDone" and "isCompleted" seems kind of similar... Would it be better if you change "isCompleted" to "getCompletionStatus"?

I think using 'this' keyword is a plus point.

Would it be better to use an explicit access modifier?

'''suggestion

private LocalDate date;

'''

Would it be better to handle the exceptions instead?

Might be better to use a more descriptive variable name

I think we should try to avoid using acronyms when naming variables. It might seem harmless now, but when the program gets big, it comes back to bite you. I too find myself guilty of this mistake

'''suggestion

    try (ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream(filepath));

'''

You might want to add a 'todo' comment here. In a big project, it will make it easier to navigate tasks that are put off to a later time

'''suggestion

        e.printStackTrace(); // Todo: handle exception

'''

Watch out for indentation. I am fine with it but some people may find it annoying

'''suggestion

        ObjectOutputStream oos = new ObjectOutputStream(tasks)) {

'''

I think you forgot to initialize tasks

'''suggestion

TaskList(){

    this.tasks = new ArrayList<>();

}

'''

When the code gets long, perhaps it would be a good idea to add single line comments.

'''suggestion

            } else if (command.startsWith("delete")) {

                // Remove the task from list

'''

I think you forgot to remove this

printStackTrace possibly left behind unintentionally

Should we allow acronyms as variable names for short codes?

Maybe we could use getter and setters

Might be a good idea to use public static final

'''suggestion

public static final DateTimeFormatter FORMATTER =

'''

Personally, i recommend using the same variable name throughout

Would be a good idea to add single line comments when the code gets long. It helps you to understand your code after being away for a long duration

'''suggestion

        // Comment on functionality of code

        BufferedReader br = new BufferedReader(new FileReader(saved));

'''

Would be good to add javadoc to constructors too

Constructor javadocs are especially important when it comes to Exceptions. Personally, i just copy Java11's exception javadocs (and credit the java11 website)

'''suggestion

/**

 * Description

 * @params message

 **/

public DukeException(String message) {

'''

just a minor nitpicking. Note the variable names

I personally do it this way

'''suggestion

        Command command = Parser.parseCommand("event read book /at 2020-10-10 20:00");

        assertTrue(command instanceof EventCommand);

'''

Better to keep the formatter in one place

'''suggestion

DateTimeFormatter formatter = Storage.FORMATTER;

'''

Hi, i think it would be nice to add java docs for this!

did you forget to add in an access modifier here?

Can add in java docs here too!

Think you can add java docs here too!

Noticed that java docs are missing for all the classes and methods, might be good to add it in!

Access modifier missing here perhaps?

Nice use of streams, never thought about it that way, good job!

If I'm not wrong, i think we are not allowed to use * for imports?

Should there be java docs for this method? I noticed quite a few methods without java docs. While it is not that necessary yet, it might be good to add them in.

I think you forgot to capitalize the first letter and made a typo for 'interface'

Would be good to leave a line after the imports

Think you can add java docs header about what this class does. Eg, Responsible for launching javafx interface

I think you can add in java docs for this method!

Can add in java docs here too!

Same here for java docs!

Can add java docs here too!

i think it would be helpful to leave a line to separate the static variables with the non-static ones.

i think you can abstract all the methods out because your line of code is slightly long? >30 lines

Again, i think you can abstract all the methods out so that your code is easier to read!

there is alot of statements nested inside your code so it somewhat has an arrowhead format, will be good to abstract the methods out!

Should there be java docs for this class?

I really like how you use enum here to define the different commands!

I really like how you implemented the Consumer interface for this class!

Consider naming the boolean something like shouldPrint to make it sound more like a boolean?

Maybe you can leave out the this keyword when it is not needed to reduce unnecessary noise?

Perhaps a more descriptive name here would help the reader understand what the string represents?

Maybe leave out the this keyword when it's not needed to make the code more succinct?

This method is quite long. Perhaps you could abstract away parts to make it more readable?

Perhaps use camel casing here, since file path is not a constant, but varies between instances of the Storage class?

Perhaps you could make use of polymorphism here, since all 3 task types extends the Task class. This can help make the code a lot more succinct and readable.

Maybe naming the method with a verb can help the program be more understandable?

Maybe using guard clauses here can ensure that your main program logic is more prominent?

Perhaps import classes explicitly here?

Maybe break up this line to make it more readable?

Maybe a header comment here can help readers understand what the method does?

Maybe naming the boolean to something like isDone can make this sound more like a boolean?

The naming of the parameter boo might not be very understandable. Perhaps also naming it as isDone would work?

I like how you placed the line break here to clearly distinguish between the imports from different packages!

Perhaps consider using the printf method here to reduce the amount of string concatenations?

Consider breaking the line before the operator (+ in this case), since it might be confusing for people to see a new line beginning with a string.

Love the idea of the enumeration of TaskSymbol!

Perhaps you could add the final modifier and change the naming style to uppercase snake case, since these strings are not meant to be changed?

Maybe you can consider specifying the data type of your variables instead of just using 'var' for all of them? I'm not sure about the technical benefits of using int, boolean, String etc but it would definitely improve the readability of your code which will be helpful for your tP! Also, it seems like all of them are boolean values so you could consider naming them isCorrect, isDeleted, isInputDone etc to follow the coding standard.

Not sure if you already know but order.substring(0 , 4).equals("done") could be replaced with order.startsWith("done"), just to improve readability but you will get the same result either way.

One possible way to make the printing of the tasks out neater could be by overriding the toString method of your Task class so that you can just call System.out.println(i + 1 + ". " + orders.get(i)) instead. It is the same logic as what you are doing here, just that the checking of status and category is done inside the Task class and this will help with abstraction.

I'm not sure why you decided to make another if block to check for todo, event, and deadline since you already checked for the booleans at lines 117, 126 and 137. Would combining the bodies of the 2 if blocks of todo change the output in any way?

Does the status(0, 1) refer to whether or not the task is done? If that's the case, changing it to a boolean(eg. isDone) will be helpful in terms of readability. It might reduce confusion as your teammates will not have to guess which variable does what when they read your code for tP/ other group projects in the future.

The status of the task is always set to 0 when you initialize a new Task object, so the constructor may not have to take in a parameter for status and this.status = 0; could be used instead?

I'm sorry but I don't really understand this part. Would it be possible to combine all the try blocks together into one and have multiple catch blocks for different errors instead?

There should be a punctuation (full-stop) behind each parameter description.

Remember to put an empty line between description and parameter section.

I think we need to include a full-stop at the back of the summary to indicate the end of the sentence, so that Javadoc will automatically place it in the method summary table(of your API)?

I think we still need to import every single class specifically instead of using a wildcard(*), even if all of the classes in that package is being used. I went to google about this a little but there are conflicting answers as to whether wildcards should be used or not, so maybe you can clarify it with your TA/the profs?

There's a few extra spaces here.

There's one extra space here, not sure if it is a violation but you might want to delete it so that your code will look more consistent throughout? There is one extra space at line 65 too

Interesting way of using a for loop, I'm not very sure how it works but if (String) line is not updated then maybe you can use a while loop instead?

Not a violation but you could follow the format of showTaskDeleted to improve readability!

Random empty space here

Need to add a space above!

Need space above this line.

Need space above this line?

Extra spaces in lines 8, 11 and 12

Why got so many spaces haha. This is not a violation so I don't want to keep spamming the same comment.

Just in case if you want to fix the extra spaces for the sake of aesthetics, here are some which I found in other files which I didn't comment:

TodoCommand.java - line 12

Event.java - line 3

UiTest.java - line 14

I found this online! (source: https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html#exclude-from-auto-import)

Disable wildcard imports to always import single classes:

In the Settings/Preferences dialog Ctrl+Alt+S, select Code Style | Java | Imports.
Make sure that the Use single class import option is enabled.
In the Class count to use import with ‘’ and Names count to use static import with ‘’ fields, specify values that definitely exceed the number of classes in a package and the number of names in a class (for example, 999).

This is incorrect because there should not be any indentation for the case clauses.

There should be a punctuation behind every parameter description. I have noticed similar issue in other places too.

This is incorrect as comments should be indented relative to their position in the code.

Perhaps putting the class in a package?

The imported classes should be listed explicitly.

Perhaps a more intuitive variable name that will sound more like a boolean?

This is incorrect as there should be an empty line between the description and parameter. I have noticed similar issues in several other places too.

Perhaps adding a short summary of the method? This can also apply to other methods that do not have a description in other places.

The indentation is not in line with the rest.

Perhaps include JavaDoc and specify what the class does? This can also apply to the other classes that do not have JavaDoc written.

Perhaps the code can be put in 1 try-catch block?

Should the parenthesis after the case clause be taken out for better readability?

Perhaps having a more intuitive variable name to make it sound more like a boolean?

Should there be a punctuation at the end of the description? I have noticed similar issue in other places too.

Should there be a break before the operator?

Perhaps it would be possible to concatenate the variable temp altogether?

Perhaps this part can be done in the Parser class?

There should be a punctuation behind the description

Perhaps rephrasing the sentence so that the action word "Throws" is used instead of "Thrown"?

Perhaps a more intuitive variable name to sound more like a boolean?

Should there be a space between while and the parathesis?

I agree with @raythx98 and @josiahkhoo on this point as well, abstraction would decrease the LOC, making the method more readable.

In addition, could you abstract this method (and potentially other methods such as printTaskList) itself to the TaskList class?

Should this method be moved to the Storage class?

Following the SLAP principle (Single Level of Abstraction Per method), perhaps this should be abstracted into a method of its own in the Storage class (e.g. populateTaskList)?

I noticed multiple try/catch blocks embedded in this method. Would it be possible to catch all the different types of exceptions in the most external try/catch block and handle them respectively, to improve code organisation?

Should this file path be saved as a final constant? This would allow you to reference it from a single place, rather than creating multiple of the same variable.

Should the final else statement be used to add a task, or should it be in an "else if" block of its own?

Should the break be before the '+' operator rather than after?

Should there be space before and after the '-' operator?

Should you handle this special condition at the beginning of the method?

Should the user's input be written verbatim into the file?

Should this JavaDoc comment end with a full stop?

Should these constant names be capitalised?

Should this boolean be named to sound like a boolean?

Should there be a space before the colon?

Should this String have a more descriptive name?

Should this class be named with a singular noun instead of a plural noun?

Should the variable datetimeDue be in camelCase? (e.g. dateTimeDue) I noticed similarly named variables in other places too, usually containing the substring "datetime".

Should these associated constants (final variables) be prefixed by a common type name in uppercase? (e.g. IMAGE_USER and IMAGE_DUKE)

Should this bool variable name be more descriptive?

I also noticed many constructors had the identical JavaDocs summary as highlighted above. Should they be more descriptive and name the class being instantiated?

Perhaps you could add a space between the curly bracket and catch.

Should indentation for case clauses be removed?

I think there should be a space between the method and the curly bracket.

I think there should be a space between 'for' and the bracket and another space at the end before the curly bracket.

I think there should be a space between 'if' and the bracket and another space at the end before the curly bracket.

I like how the line break comes before the || operator. The 8 space indentation is also good.

Perhaps the line break should come before the + operator.

I think there should be a space between 'if' and the bracket and another space at the end before the curly bracket.

I think there should be a space between 'for' and the bracket and another space at the end before the curly bracket.

I think you might have accidentally declared the Event class twice?

I like how the line break comes before the + operator.

The name of this boolean method sounds like a boolean, which is good.

Perhaps the String should be 'private static final'? Either that, or it should not be capitalised and separated by underscores since it is not a constant.

Perhaps the line breaks should come before the + operators.

Perhaps the method could be named confirmTaskDeletion instead?

Perhaps the method could be named confirmTaskAddition instead?

Perhaps the method could be named printDoneMessage instead?

I think usage of stars should be avoided!

As "command" represent a list, should we change it to "commands" ?

Format of javadoc is different from guidlines.

Shoud FILE_PATH be a better choice here?

Maybe we should have spaces before open curly brackets "{".

This expression maybe a little bit complicated, readers may not understand the logics behind.

This can be dangerous! newTask maybe uninitialized

Should we change this to returnSearchTasks?

Should we rename it, since it is a void, but having name of a noun?

This may be dangerous.

This part is a little bit long, and maybe messy. I think we should avoid long methods by abstracting it (usage of polymorphism).

Is it better that we handle these exceptions so that Duke can keep running?

This method returns something. Based on naming guidlines, should we change the method's name to a noun?

This part may be abstracted to read more easily.

Maybe we should avoid using "magic numbers" ?

Should we have Javadoc here?

Should we change it to getNumTasks?

I think stars should be avoided

Should we change taskString to taskStrings as it represents a list?

As in coding standard guidelines, all objects should be initialized when declared.

Perhaps you can use a switch statement here instead of an if-else statement to improve code readability?

I like the naming of the boolean method. However, should this public method have a header comment? See here. I noticed the same issue in several other places too.

Should this method name be in the form of a verb instead? E.g. printWelcomeCommand(). I noticed the same issue in several other places too.

Should you use a switch-case statement here instead?

Should there be a spacing after "//" for comments? I noticed the same issue elsewhere too.

This method seems to be particularly long and quite convoluted. Perhaps you can consider the following methods to make it more readable:

Break the code into logic blocks and abstract them into separate methods.
Write more comments to explain what each logic block handles.
Use more switch-case statements or else-if statements, instead of many nested if and else statements.

Should there be a @return param here?

Should you remove the this keyword? The java coding standard documentation mentions to use this keyword only when a field is shadowed by a method or constructor parameter. I've noticed this issue in several other places as well.

Should there be a punctuation at the end of the dateTime param? I see that you did it in most other params as well, might have missed this out.

Perhaps the comments beside each case block can be more descriptive? Otherwise, maybe you can do away with the comments as they are repeating the words in the cases. 😃

I'm not too sure if this rule applies to constructors as well, but should the first sentence of the method header comment start in the form of "Constructs ..."? See Java Coding Standard -> Comments.

Should you remove the this keyword? The java coding standard documentation mentions to use this keyword only when a field is shadowed by a method or constructor parameter.

Should there be a punctuation at the end of this comment sentence as well? 😃

Should this method be private since it is only used within the class? I noticed the same issue in several other places too.

Should this Boolean variable name be "isDirCreated"? The java coding standard documentation states that Boolean variables/method should be named to sound like booleans. I notice similar issues regarding the naming of Boolean variables elsewhere as well, perhaps you can do a quick look through your Boolean variable names! 😃

I like the form of your switch statements! 👍

Should the public methods have header comments? I notice that public methods in some files do not have header comments.

I like your indentation style! 👍

Should this method name be in the form of a verb instead? E.g. printFareWellMessage(). See Java Coding Standard -> Naming. I notice the same issue a few times in this file as well.

Should the '+' operator be in line 44 instead of line 43? See here.

There is a missing space after the equal sign.

Same as above.

I think you can include some descriptions about the method and the parameter.

Should the method's name be in verb form?

Would it be better to put the comment above the statement?

Should it be "Represent(s) ..." ?

Should a description of the method be added here?

Should it be "Loads ..." ?

Should it be "Saves..." ?

Should a description of the method be added here?

Should there be indentations for the case clauses?

Should a description of the method added here?

Should the abundant spaces between the parameter and its description be removed?

Should the abundant spaces between the parameter and its description be removed? I notice the same issue at other places too.

Should unwanted code be deleted instead of commented out?

I think it will be neater if the variables come before the constructor?

I think it should be checkDoneness instead of checkDoness? Remember to check the Javadoc for Event too.

Consider including a default branch, even if it only contains break?

I believe there should be a space before prints? Also, don't forget to end your sentences in all your Javadocs with a full stop 😊

Consider breaking this line before the last + operator? I noticed the same issue in several other places too.

Consider making them static final?

Consider including a default branch with break here too?

I believe in this case it should be Returns and not Prints?

I think taskListing should be task list?

Seems like a small typo with the second *?

It seems like doneness should be some variation of getDoneness and checkDoneness should be some variation of setDoneness? Please correct me if I am wrong

Yes under the part on layout in the java coding standards. To quote,

Break before an operator. This also applies to the following "operator-like" symbols: the dot separator ., the ampersand in type bounds <t extends Foo & Bar cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\ip-review-comments-panels.mbdf">, and the pipe in catch blocks catch (FooException | BarException e)

There are also some examples on that page with the + on a new line.

I think the convention is to put the constructor currently on line 8 after your instance variables from lines 12 to 16? Correct me if I am wrong

https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html

Looks good! 👍

Consider putting the comment above the line? I noticed the same issue in several other places too but I think this is a matter of personal preference so it is not major.

Do you mean If an empty item description is given?

Seems like a missing full stop?

Consider using slightly more descriptive variable names?

Perhaps update the javadoc for both AddCommand and ListCommand?

While it can be seen what this method does from @param and @return, perhaps a little more information on that in the description will be helpful?

Perhaps you could edit this Javadoc comment to describe your completed method?

Should this public method come along with a Javadoc comment?

Should this public method come along with a Javadoc comment? I noticed similar issues in other classes as well.

Is there a missing statement within the Javadoc comment to describe the what the method returns?

Perhaps the variable name should be a noun instead?

Perhaps you could avoid deep nesting in the body of this method? Since this method is longer than 30 LOC, maybe you could split into several methods or classes?

Perhaps you could shorten this method by extracting some LOC into several other methods or classes?

Perhaps you could avoid deep nesting in this method body? I noticed the same issue in several other classes as well.

Perhaps the String[] toFind could be better named to reflect the variable it contains?

Should the class name be a noun instead (i.e. CommandFinder)?

Should the class name be a noun instead? I noticed the same issue with the naming of several other classes as well.

Should this method include a Javadoc comment?

Should this class include a Javadoc comment?

Should this method include a Javadoc comment? I noticed the same issue in several other methods and classes too.

Should there be a punctuation behind each parameter description? I noticed the same issue in several other Javadoc comments too.

Perhaps you could standardize if the description of each @param after the parameter name begins with an uppercase or not?

Also, should there be a punctuation behind each parameter description?

Should this be phrased as "Removes ..." rather than "Remove ..."?

Should this be phrased as "Returns a ..."?

Should there be an empty line between the description and parameter section?

Perhaps the test method name could be better constructed to follow the format: featureUnderTest_testScenario_expectedBehavior()? I noticed the same issue in most of the other test methods as well.

You might want to use a more descriptive name like taskList than just list.

Agree with this comment.

Agree with this comment, though as this is just a temporary variable, it is not too big an issue.

There's an extra blank line here before the closing brace as well. Should remove to follow coding standards.

There is an extra blank line here before the closing brace.

Agree with this comment. Perhaps give it a more descriptive name?

There are 2 blank lines here, but one blank line between other methods. Try to keep it to one line between methods for consistency.

Not explicitly in the coding standard, but as highlighted by GitHub here and based on personal experience, I think it is tradition/standard in many places to end a file with a new (blank) line.

You have 3 blank lines between methods here. Perhaps consider keeping to just 1 line for consistency.

There is a blank line before the closing brace. Consider removing to reduce the number of lines.

Naming a new line as error and then overriding it with an actual error may be confusing. Perhaps consider making separate variables for each.

Not explicitly in the coding standards, but I think it's traditional / standard practice to end a file with a blank new line, as highlighted by GitHub here.

Javadoc not descriptive of function! I think you copy-pasted and forgot to change here. 😝

I think this is not an issue as this is a scratch variable used only on this line.

Seems like the purpose of this function is to catch an exception and throw a different exception in its place. Not sure if this is good practice as it may mask errors.

Agree with this. Perhaps consider renaming it to something more specific?

Perhaps consider naming it just lineBreak? Naming it lineBreaker makes it seem like it has a function.

Agree with this. details does not identify it as a LocalDate object, though as this is just a temporary variable it is not a big issue.

You named Scanner as scanner in some classes, and s in others. Do consider keeping the names consistent for ease of reading the code.

Can't do gradle-tasks-application-run currently. I believe this line should be changed to

mainClassName = "duke.Duke"

I'd suggest adding this to your gitignore

Consider using LocalDateTime instead.

Look up ISO 8601.

There probably is an existing API method for this

This logic should be in DateAndTime (if you choose to keep that class), especially because this is the only place the constructor is used

The word "line" is ambiguous, as in system.out.println. Maybe call it printDivider instead?

Meaning of "des" should be explained.

createDirectory already checks if the directory exists.

Same comment as createDirectory.

Perhaps this should be called loadTasks, as it can load multiple.

Seems like loadTask can be absorbed into this function.

Consider using serialization instead. Otherwise, good practice would be to write tests for the conversion methods here.

Redundant comment, there's no need to explain what strip does (it has its own javadocs).

Nice! Could be absorbed into toString as both methods are short.

Should add a blank line between description and param.

Great use of try-catch!

Shadows line 14.

Can be final.

This might have been missed while merging! Should this be here?

Would it be clearer to list the imported classes explicitly?

Should this variable be named "ui" instead?

I like that you made classes for the specific types of exceptions!

Should the call to .substring be formatted in a better way? Noticed this in a few other places as well!

Should there be better spacing with the '+'s?

Should there be an explanation on why this method executes nothing? I expected it to be the method that terminates the application.

Should this method be returning false? It's currently returning true.

Should this JavaDoc be in the next line?

Should this line be 1 extra line below the previous? Noticed this in some other places too!

Noticed some extra lines after JavaDocs. Should the JavaDoc style be consistent?

Should this line be better spaced?

Should the indentation for "case" be 1 tab less?

Should there be newline at end of file? Noticed this in some other places too!

Might "splitString" be a better name for this method?

Might "splitStringWithLimit" be a better name for this method?

Might "getTasksContaining" be a better name for this metohd?

Might "saveTasks" be a better name for this method?

Might SAVE_PATH be a better name for this variable?

Could the name "inputs" be a little more precise when it comes to referring a TaskList?

Do you think adding a JavaDoc description here would allow other users to better understand what exactly Duke does?

Missing full stop for JavaDoc here!

Interesting use of static classes and interfaces here!

You could try naming this boolean more like a boolean, something like isDone.

Might be a little typo here, but don't forget to caps the first letter of the sentence!

I realised the use of substring to get specific keywords from the user input. An alternative to this would be to use the split() function of String to split the user input up!

Maybe you can consider making this more succint. In other words, try to avoid nesting conditionals which could get quite messy, though I am guilty of this too!

Are these missing their access modifiers? It would be best to make them private!

You could try making these code more succint by nesting lesser conditionals together!

You could try using the tick symbol instead of a '/'. The four-digit hex code for the tick symbol is \u2713.

Interesting way of parsing user input here!

Should you add an error message for DateTimeParseException to give more informative feedback to user?

Cool idea of placing the runCommand function in the TaskList clear. An alternative could be placing this function in the respective Command classes!

You could possibly do away with the curly braces for the case blocks!

Be careful with using contains here because it might lead to unexpected search results! Take for example, if I did something like this:

String input = "basement";

input.contains(base) will return true which might not be intended!

Similarly, you could do away with the curly braces here for the case blocks!

Interesting toStore function here!

Maybe this could be worded more precisely. Meaning you could add what the user input is and what the expected outcome is in the test name.

I think the Duke class should have its own package statement.

Should the main method have its own documentation since it is a public method?

Should this method have JavaDocs documentation ? Likewise for the the other exception class' methods 😃

Should there be a space between the class declaration and the first bracket ?

I think there are a few more instances.

Should we bulk import packages?

I think the "Construct..." should be on a new line.

Should we explicitly set the visibility of our class variables?

I think we should end our JavaDoc sentences with a full stop.

Is this the correct form for if-else blocks?

Should we have a JavaDocs comment for the class description ?

Should there be a space here?

I think you forgot the documentation for this method.

Is your indentation correct ?

Should there be a space between the method description and parameter section?

I think you forgot to add documentation for this method.

Perhaps the variable could have a slightly more descriptive name?

found sounds alright but I don't know if it is required for it to be named as a question. 🤔

Perhaps we should not abbreviate variable names?

Perhaps try to name the boolean variable as a question?

A Javadoc comment would be more appropriate here since the reader might not know what you are referring to

Comment might be unnecessary here since the method name is quite self-explanatory

Perhaps include more line breaks to make it more readable?

Seems like an unnecessary class member. Maybe declare a local variable if you do want to use it since it is not used elsewhere in the class?

Consider using an enumeration and declaring these as members of respective sub-classes as a particular class's command would be unnecessary and out-of-scope for all other classes.

Comment seems to contain a little unnecessary/misplaced information. Information on the class members can be given using their own javadocs.

Javadocs for Command sub-classes could be more concise as comments on execute already include some information.

Code like this seems like its breaking abstraction. Is there a way Ui could be refactored to process the messages internally?

Can this be abstracted as it is repeated in both Event and Deadline creation?

This could also be abstracted into the Ui class where it can handle all the formatting in one place.

This seems like another possible case of breaking abstraction. Consider including a method for the two types of Tasks to make this check themselves.

Same as in ShowAfterCommand

Comments could be more concise. By convention usually the "how" is not really included in comments.

Comments on toString methods of Exception sub-classes seem unnecessary as method is self-explanatory.

Code seems to be repeated/very similar. Have you considered abstracting it into a method?

In these checks, consider using startswith or a more appropriate check as it might find the keyword anywhere within the input.

Repeated/similar code, possibility to abstract into a method?

Naming of these methods seem a bit misleading. Consider naming them as print... or output...

Could be better names as a verb, e.g. requestCommand?

Should the enum instances be fully capitalized?

Maybe list out the imports explicitly instead of using .*?

Maybe arrange the imports in lexicology order?

Maybe split this line into different lines for better readability?

Did you forget to remove this line?

Maybe extract the components in this method into different methods? There is a lot of information in just 1 method.

Remember to delete this if you're not using it in your code!

Maybe extract out some parts of this method to shorten it? This method may become even longer as more functions of the application is added later on.

Maybe explicitly importing each line rather than using .* would be clearer?

Maybe changed the naming of this variable to isCompleted?

Good work extracting out the different exceptions!

Maybe extract the number 3 into a static variable? That would make what the number 3 stands for clearer.

Maybe extract the number 4 into a static variable?

Would it be clearer if you stored the numbers for length of "todo", "deadline" and "event" as variables?

cute!

Is there a reason you used 4 spaces instead of INDENT like before?

is it necessary to have the "//" comment if the format is already show in javadoc comment?

What are these lines for?

Good work storing the task types as enums!

It is required in the style guide to list out imported classes explicitly instead of using wildcard.

I think it is recommended to have the packages in all lower case.

Perhaps, the class header should be more of what to expect of the class rather than a description of one of its methods

Please put a white space after keywords such as if and while, and also after the closing parenthesis and before the braces.

Similarly, white spaces are missing here.

P.S. I notice the same issue elsewhere. I will stop commenting on this issue.

You may want to consider reducing the length of this function and also it may be a good idea to not nest conditional stmts inside the condition as there are already many conditional stmts. Blocks of code that are commented out can be removed.

I would write addToList instead

Please leave a line between the description and @param. Perhaps you would want to add more information on the param

Is this needed? Perhaps you could add @override above too.

I like how the constants are grouped together and named.

Please leave a line after the description.

P.S. this applies to other javadocs too. I will stop commenting on this issue:)

Perhaps, you could remove this?

Perhaps, the language and punctuation can be improved. Such as period at the end of the sentences.

Perhaps .strip() can be used here instead as it is unicode compliant

I like how 'String.format()' is used and StringBuilder is used as it is not a short string.

I like how a list of patterns is used to allow more flexibility in user's input for date and time.

I feel like this can be shortened with a loop or switch case. Did you do it this way because it might be more readable?

To me, one function for each type of command seems a bit excessive. Perhaps, there are other ways you would like to shorten this and make it seem less repetitive?

Given the multiple formats allow, perhaps you would want to test other valid and invalid inputs as well.

Maybe shall we change the method name to be more detailed such as parseCommand ?

As the scope of f is the load() method, which is not very small, maybe shall we change the variable name to file to be longer and more detailed?

Shall we change the test method name to testRecordString() to be more detailed and specific?

Maybe shall we change protected to private ?

I really like this coding practice here as the code makes use of the default branch to detect possible errors and throw out exceptions.

Maybe shall we change the naming of directoryMade to isDirectoryMade?

Maybe shall we change the naming of this method to getSize()? As it may sound more like an action.

I think the naming of the method is generally okay. But I think that maybe shall we change it to displayList(TaskList tasks) to make it more detailed and specific? The same applies to the other method namings below.

Maybe shall we change the naming to initializeDukeUi with a lower-case "i"?

Shall we add a description of the return value(@return) here in Javadoc?

The coding style looks good! I really like this as it is nice and clean. 👍

Shall we add one blank line here between the overall description and @return in Javadoc? I think this may also apply to other Javadoc as well.

Shall we use Lists out the saved tasks ... here in Javadoc description?

Shall we use Marks the task... here?

Shall we add a //Fallthrough comment here as this is a case statement without a break statement.

Shall we add a blank line between the package statement and the import statement here?

Maybe shall we try to avoid naming variables using number index(e2) here? But indeed as it has a very small scope, thus I think the naming may also be okay.

Shall we add a description of the parameters of this method in the Javadoc as well? This suggestion also applies to the Javadoc of other methods as well.

missing header comment for public method

nice constant names!

need line separation between description and @return/@param (for other javadoc also)

nice test names!

isCompleted

header comments (for other public classes too)

//unknown input on same indentation as line below

me too

empty line between description and parameter sections

method is a bit long, maybe can separate the first file creation part into another method?

nice error catching 😃

header comment for public class (for event/task/tasklist ..)

i like the tutorial!! nice hehe

nice test names 😃

ah nice, very thoughtful for user hehe

empty line

maybe can abstract file creation and reader/writer creation to before the switch statement?

maybe storage.writeToFile and success statement can be abstracted to outside of the switch statement also? can improve readability 😃

Should it these enum constants be in all caps?

boolean method can be named isDone() instead.

Very clean psvm method!

Perhaps a line space between properties and the class constructor.

Perhaps a line space between properties and class constructor.

Perhaps add a space between Javadoc description and @param (line 6 and 7).

Perhaps boolean can be named "isDone"?

Perhaps you can leave a line space between line 43 and line 44

Perhaps change the method name to "printErrorMessage" or "printErrorMsg" as mentioned by Zhi Yuan.

Enums are constants so perhaps it is fine to be fully capitalised.

Perhaps you may avoid the usage of * in import statements because it will help you and other developers easily understand the code base when all the classes have been grouped in packages.

Perhaps the variable line can be final, with capitalised variable name as a constant?

Maybe you can leave a line between methods? (between line 30 and line 31)

Perhaps this empty space at line 80 can be removed?

Perhaps bot.chat(sc.nextLine()) can be added under the while loop instead of the conditional cases to make the while loop clearer?

Perhaps as Jian Ling mentioned, you can extract out the methods and break the long chunk of code down into smaller methods to make this method cleaner?

Perhaps you may avoid the usage of * in import statements because it will help you and other developers easily understand the code base when all the classes have been grouped in packages.

Perhaps the description of javadocs can start with "Marks" instead of "Mark"?

Perhaps you could leave a space between try and the opening curly brace?

Same issue as above for the catch statement.

Please have some spacing here as well. I noticed this in other places as well perhaps you can look through your code and change them accordingly.

I believe you can use \t instead of 4 white spaces to represent a tab.

You might want to separate them accordingly?

Good job on the good readability of the if-else statement 👍

Maybe the "?" should be on the next line?

Same issue as above. I noticed this in other places as well perhaps you can look through your code and change them accordingly.

You might want to add some spacing here? I noticed this in other places as well perhaps you can look through your code and change them accordingly.

Perhaps you can put this line inside an else block as it is a condition for 'everything else'?

You might want to put this in a if-elseif-else statement?

Maybe you want to explicitly import the classes and avoid wildcards?

Same issue listed above. I noticed this in other places as well perhaps you can look through your code and change them accordingly.

Perhaps you can separate java.io imports from java.util?

You might want to add a default condition for the switch statement? I feel this can alert the user in case they accidentally open up the txt file and change the first value to something else.

Wow. This is art 💯

You might want to include a default statement here? I believe this will ensure the 'type' you pass into this function has no spelling errors for easier debugging.

Perhaps can consider changing the method name to become more descriptive. (e.g. runChatbot() or runApplication()).

Perhaps can consider changing the variable input to something like userCommand.

Perhaps can consider changing the method name into getNumOfTasks().

Perhaps can consider changing the method name into checkSavedFile().

Consider initializing the task variable first.

Perhaps consider changing the variable i into index to be more descriptive.

Consider changing the variable at into something more descriptive.

Good job for using the UTF representation!

Perhaps can explain more clearly what does it mean by having an invalidInput?

Perhaps can consider changing the variable de to be more descriptive.

Can consider changing the variable ev to be more descriptive (e.g. eventInput)

Perhaps can consider changing this variable name to be more descriptive. (e.g taskDeadline)

Consider changing the method name to be more explanatory, so to avoid ambiguity between other execute methods from other classes.

I noticed you used the word execute quite frequently. Perhaps can consider changing it to be more class-specific so as to avoid ambiguity.

Perhaps can consider checking the coding convention for switch cases, I recall that case should be aligned with the switch command in terms of spacing. 👍

Can consider making the method name more descriptive like readFromFile().

Consider following the convention for writing testing methods: featureUnderTest_testScenario_expectedBehavior(). For this case, maybe can consider changing it into parseCommands_validTodoInput_success()

Consider following the convention for writing testing methods: featureUnderTest_testScenario_expectedBehavior(). For this case, maybe can consider changing it into getTask_validTaskInput_success()

Should there be whitespace after "if"? I noticed the same issue in several other places too.

Reference: "Java reserved words should be followed by a white space." from CS2103 Java coding standard web page

Should the name of the boolean be "isExist"? I also noticed the same issue in other boolean variables too.

Reference: "Boolean variables/methods should be named to sound like booleans"

Hi, should there be a package statement above this line?

Reference: "Every class should be part of some package."

Should the plus sign at the end of the line be placed below instead (i.e. after the break)?

Reference: "Break before an operator."

Should this be declared as non-public? I also see the same issue on some other variables.

Reference: "Class variables should never be declared public unless the class is a data class with no behavior."

it actually depends on how the directory in your project looks like. one of my package statements is "package command"

I'm not 100% sure, but I think it means methods

Should the userinput become userInput instead (camelCase)?

Should the variable name ("by") be a noun?

It might be only me, but I personally think eventArr would be some kind of array containing some events. Perhaps a name that could describe that it is a pair of description and time?

I'm not 100% sure, but I feel that "writeData" is more of a verb instead of a noun. Perhaps a name that sounds more like a noun? This is also the case for "writeStream" below

This is a similar case from "writeData", but I like this one more! This is because "writeData" sounds like a verb, while "readData" sounds like a noun if we read the "read" as the past form of the verb "read".

Although the scope of "s" is small, should it be more descriptive?

Should "search" be a noun?

Should the "at" be a noun? I also found other similar cases

Should "in" be a noun?

Should this be userImage and dukeImage so that it's consistent with the "MainWindow" file, and to avoid confusion between a Duke instance (of class Duke) and duke image (of class Image)?

Should "temp" be more descriptive?

Could you remove this line, as per Google Java Styleguide?

VALID_COMMAND probably should be renamed as VALID_COMMANDS

The cases have a wrong indentation level, as per SEEDU's java coding standard. Unfortunately this one is one that IntelliJ won't catch 😦

Have you tried the edgecase of just space characters? Might want to look into Java's String.strip() method.

Could you remove this line, as per Google Java Styleguide?

Could you remove the line break here, as per Google Java Style Guide?

Agreed, it would probably be better if the java.util.ArrayList is separated in a new line.

Perhaps a more descriptive variable name would be more apt here.

Perhaps the parameter should not be named dateTime as it might imply that it includes a time?

It may be better to have a new line at the end of the file to follow standard conventions.

It would be good to add javadocs comments for all the public methods.

Perhaps there should be an access modifier here.

Why do you choose to use if-else statements over switch-case?

Would this seem a little repetitive with GuiParser?

Why is everything commented out? Perhaps this file should be deleted if it is no longer needed.

It may be clearer to have line breaks between different fields or methods.

It would help the reader if more information were given about each parameter.

Would it be more understandable if the method name describes what this method is doing, for example, stripAndTokenizeCommand() as it is unclear what processedCommand and furtherProcessing does. Method names also should be in verb form.

Why is this called init()?

Missing whitespace after for.

case and switch should have the same indentation (according to the CS2103 style guide).

Missing javadoc comment.

I am confused why the javadoc says that the method returns a data although it returns "success" or "error".

All the above methods are process something but it would be clearer if the method name describes what the method is doing more specifically.

Why do you choose to put some processing methods in this class rather than in the Parser class or at least in another class? Do you think it would demonstrate better encapsulation if Duke was not in charge of the processing of user inputs?

May I suggest for improved readability that there be an extra line break between each case block?

I like how you have written a method for each task class so that they are converted into String form for writing into the hard disk.

I like how you have written header comments for nearly all your functions. Your JavaDocs are clear and easy to understand.

May I suggest renaming using EventTask instead? I feel that an EventTask will more accurately reflect its inheritance from Task.

Perhaps it would make the code cleaner if these commented code are completely removed? Otherwise , leaving to the end of the java file is good too.

Here is a small personal preference. I would suggest using a ternary operator so that "task" would be used instead of "tasks" if listLength is 0 or 1.

In addition, may I point out that the plus operator is not in front of the next line? I noticed an inconsistency within this method in comparison to showDeleteTask and showWelcome.

Hi, I noticed a contrast where myTaskList has a final modifier, but myTaskList is directly modified in the later code by adding to the list. May I ask what the reason for adding the final modifier is?

I believe that Coding Standard stated that there should be no spacing between JavaDoc and the method declaration. Perhaps if you could take some time to check it?

For ease of reading, I would prefer separating each append into a new line.

I find that 's' is not quite descriptive for a method argument name. I would suggest using "description" instead to make it more meaningful.

May I suggest using a switch block instead? I find it would make the code more readable since each line would be shorter.

E.g.

case "deadline":

instead of

else if (input.startsWith("deadline"))

May I suggest grouping the ternary operator entirely in a new line as follows?

super("☹ OOPS!!! Please enter a valid task index to be "

            + (command.startsWith("done") ? "marked as done." : "deleted."));

May I suggest adding more line inputs with respect to the increasing levels? I find that maintaining this text assists greatly with testing.

May I suggest putting the Parser and Storage class within a IO package?

I believe within the coding standard, it is stated there should be a line break between the description and parameter block. Perhaps you check to confirm? This goes for other places within this project as well.

This block feels quite lengthy. Perhaps it would be better to add some line breaks for readability.

I believe there is quite some functions within other classes that would be better encapsulated within this class. Examples are detecting for invalid indexes, incomplete commands and so forth. I would suggest that Parser also have additional capabilities to identify invalid commands. I believe this would fall under the role of parsing the user input.

Should the imported classes be listed explicitly?

Should there be a space after if and before {?

Should you put 'else if' after the preceding '{'?

'''

if (condition) {

    statements;

} else if (condition) {

    statements;

} else {

    statements;

}

'''

Should there be an empty line between description and parameter section?

Should there be a fully stop after comment?

Should there be a space before {?

I think in general this is also applicable for other structures such as for, while and if.

Should there be an empty catch block?

I like how you use inheritance here.

Could these two variables be static so as to conserve memory?

I like these unique and interesting command names.

Since these two variables are present in more than 1 class, maybe it is possible to consolidate them into one utility class (integrate into Parser perhaps)?

Perhaps it is better to avoid this kind of clever code?

I like it though.

As the old adage goes, "keep it simple, stupid” (KISS). Do not try to write ‘clever’ code.

Should there be @param?

Should there be a line separating description and parameter section for JavaDoc?

Could this have a more descriptive name such as printDashedLine?

Maybe consider adopting the 3 part test method naming convention?

featureUnderTest_testScenario_expectedBehavior()

I like that you have a method to reset direction after all the tests.

While non-essential for private class members, perhaps you can still consider adding JavaDoc comments for them as it may be beneficial for you when a need to debug your code arises.

These comments can be specified on a single line as recommended in our textbook:

https://se-education.org/guides/conventions/java/intermediate.html#comments

under the comments segment!

It seems you have yet to add JavaDoc comments for the methods in this class as you are still working on it. Do remember to add them in when fine tuning your code! 😸

I like how you created different classes to represent different forms of exceptions! Good job for your hard work! 😄

I like how you have abstracted out all the parse logic into individual methods, thereby making your parse method easily readable!

Excellent application of the enum class!

Yup! I think Yan Cheng brought up a very good point. Allowing users to input their distinct file paths may improve the flexibility of your storage class, especially in the case where you may be required to store different types of data in different data files. Perhaps it may be possible to integrate this change by taking in a string function parameter for your createTaskStorage method where the string represents the file path.

It appears JavaDoc comments for the following class has yet to be added. Do remember to add them in when fine-tuning your file! 👍🏻

It appears JavaDoc comments for your test classes have yet to be added. Do remember to add them in when fine-tuning your file! 👍🏻

Good use of assertEquals! I really like how your tests are comprehensive as well! Great job 😄

It seems you may have missed out on adding JavaDoc comments for the following method. Do remember to add them in when fine-tuning your file! 👍🏻

Perhaps we can explore adopting a more expressive variable name here such as IndexToDelete to explain the purpose of this variable at a higher level of detail?

Similar to my previous comment in the DeleteCommand class, perhaps we can explore adopting a more specific variable name here as well! 😺

While non-essential, maybe you can consider adding this display string as a specific method in your UI class instead?

Adopting this strategy will help to shorten the code in your command classes as a simple call to maybe ui.showDoneMessage(entryDone); can be used instead of having the entire message displayed here.

It will also be easier to modify your display messages if they all reside in the same UI class. Just a point to consider 😸

Otherwise, it works fine as it is as well 👍🏻

It seems you missed out on this constructor when writing the JavaDoc for this class. Do remember to add it in when you're fine-tuning your code!

It seems there may be an extra tab in the description for this JavaDoc line.

Perhaps it may be better to use the /** */ format for writing JavaDoc for this method instead of having it within the method itself?

It seems you may have missed out on writing JavaDoc for this default constructor!

Can consider adding an empty line here so as to standardize with the rest of the files, just something trivial 👍

I like how you consolidate the possible task types in enum class for checking 👍

Should there be a space here? Eg: if[space](command...

I notice this in some other places as well, feel free to edit! 😃

Shall we privatize variables for encapsulation? If I'm not mistaken, its part of the coding standard that this mod enforces

Should there be no indentation after switch case? You can change the IDE formatting in settings for this 😃

I notice this is some other places as well. Feel free to edit

Should there be no space after "!" ?

If I remember correctly, the standard convention is that folders will be in small letters, whereas classes to start with capital letter. Maybe you can double confirm this first before the change 😃

Does your gradle able to handle building/ running your application? You can change the mainClassName into your application's class name if it does not work.

I like how you put the Commands into ENUM class for checking 😃 Great job!

Is there any reason why there is an empty line here? For this module, I think the separation of line is between description and @params. Perhaps you can consider using

to separate the description into different paragraphs 😄

I notice that the same issue in other places too. Feel free to edit!

Should there be spacing here: if[space](userInput ?

Is there any reason why you use /** instead of // ? From my understanding, /** is used for JavaDoc and // for specific comments. We can check with prof regarding this!

I like how you organized the different unit tests into its respective classes. However, is there a reason why you use assertEquals rather than assertThrows? Its not a major issue but something to consider as it will make your code neater

Just a minor spelling issue, can consider changing print's into prints 😃

Should this be prints?

I think all public classes and methods need header comments?

I dont think theres a need for indentation for case clauses?

I think you need an empty line between description and parameter section? Similar issue found in the other JavaDoc comments too!

I think you accidentally put a space after description?

I like how neat your main class is!! 💯

I like the name, cute!! 😃

Consider using this naming format for test cases?

I think you need an empty line between the description and parameters? Similar for the other JavaDoc comments too!

Perhaps using "printLine()" will be more appropriate? Use nouns for classes/variables and verbs for methods/functions. Similar problem found in other methods too.

What does Oder mean?

Is this supposed to be 'printFormat()'? Typos might make your code harder to understand.

I like how your method names explain the method well! 😃

I think you meant 'execute' here, which caused typos in the children classes as well as the JavaDoc comment.

Consider naming it to 'removedTask'?

Consider specifying this as 'deleteIndex' to make it sound clearer? Similar for Done

I like how the main class is neat!! 💯

Consider naming the test methods this way?

Should this method header comment start with Returns... or Gets... instead of the narrative sentence?

Should this method header comment start with "Analyses.." instead?

I noticed the same issue in several other places too.

I like how you added comments to different parts of the method. It improves readability.

Should this method header comment start with "Gets..." or "Returns..." instead of this narrative sentence?

Should this method header comment start with "Analyses..." instead?

I noticed the same issue in several other places too.

I like how the individual components of the method body are attached with a comment. It improves readability.

The line breaks were added at appropriate locations. Good job!

Should the name FILEPATH be expressed as FILE_PATH instead?

Perhaps the naming could be even clearer by naming them as such: userImage, dukeImage

Perhaps lines of code that weren't eventually used can be removed.

Likewise, this part of code could be removed as it was not used.

Perhaps the naming of the method can be modified to a verb, e.g. showWelcome()

Should the method header comment start with a verb instead? e.g. "Gets the response"

This method goes beyond 30 LOC (lines of code). Maybe parts of the method could be abstracted out?

Perhaps a clearer name such as "file" could be used instead?

Perhaps u can name testing methods starting with "test..." to make it sound more intuitive?

Examples: testUnderstandText(), testAddTask()

Should there be an empty like between the method description and parameters section?

Perhaps this method can be simply named as printMessage() since it is quite obvious that the message is for the users? This will also be more consistent with the other print..() methods below.

Since hard disk are two separate words, should this method be names as saveIntoHardDisk() instead?

Perhaps savedFile might sound more intuitive?

Instead of using "further", perhaps this can method can be named as understandTaskDescription()?

Instead of using "further", perhaps this can method can be simply named as understandTaskNumber()?

Should this attribute be made private?

Any reason why you did it this way instead of "\t"?

Should the first sentence of JavaDoc starts with something like "Adds..." or "Executes..."?

Should this attribute be made private? I noticed the same issue in several other places too.

Should the first sentence of JavaDoc starts with something like "Adds..." or "Executes..."? I noticed the same issue in several other places too.

Perhaps this block of code can be removed if it is not used?

Should there be an empty line between the description and parameter section?

Perhaps this attribute can be named as "isDone" instead?

Perhaps this empty line can be removed to make to code look neater?

Could this attribute be made private static final so that it is a constant variable? The naming can then be done in full uppercase with underscores.

Perhaps the this would not be necessary here.

enum members are all constants and should all be in upper case

Perhaps you might want to set them as class-level constants

Perhaps you might consider abstracting out repeated code

you might want to final this

Variable names must be in camelCase

Perhaps you might want to add access modifiers?

Perhaps you might want add a condition to check if the user wants to exit, before using Platform.exit() to terminate the javaFx window.

Nice job on the switch indentation!

Perhaps you might want to put the comment for a block of code directly above it without any spacing

Perhaps you might want consider creating a template to abstract this.

Perhaps changing it to get would be a good idea as "isXxx" sounds like a boolean variable

perhaps you might want to consider adding access modifiers to instance variables

perhaps you might want to consider removing the this. from the taskBy

Perhaps you might want to consider moving your reply method to the Ui class.

There is no indentation for case clauses.

Perhaps you might consider using an enum class for this 😃

Are you missing any parameter declarations in your JavaDocs?

Perhaps u could convert the 'splitted' collection to a plural form?

Since the ensuing logic in the deadline, todo & event blocks are similar, perhaps u could consider abstracting that away with a common method definition?

Maybe u can remove the unnecessary line here?

Perhaps instead of using instanceof to discover the object type of the task objects, maybe u can just define a separate enum class that carries all main types of tasks and then create a variable in Task abstract class for defining the type of the task?

Minor thing, Is the this. here really necessary?

Perhaps for code readability u can just rename it to welcomeMessages instead

Nice use of Optional!

JavaDocs can be updated to account for the return type of String[] this time

Really neat exemplification of abstraction with interfaces for Storage implemented by main class LocalStorage!

this. can be removed for better readability

Awesome use of streams & FP to filter out the tasks with dates!

Is the this. really necessary? Can be removed for better code readability

Really nice use of comments in your code so far! Makes it really easy to catch your flow of thought!

I understand why u named it as params, but for the purposes of the style guide could u rename to a singular form? Since plural form namings are reserved for collections.

Similar to previous comment, could perhaps rename it to plural form for better code readability.

Neat use of streams for filtering!

The comments is all good and it would be better if you can spare a new line after the description and the parameter description to make it look neater and also follow the Coding Standard

I think it would be nice if you could add some description to your constructor.

It would be nice if the comment could end with a full stop.

The comments seems good and it would be better if you could add space between the description and the param description.

Hi, I think the naming of your paramaters could be made more clearer, such that com --> command. Sometimes it is just confusing to read a contracted or shortened word.

The comments seems good and it would be better if it could start with verbs instead following the Coding Standard

The naming would be better to set as isDone instead of done, as it is a boolean data type. It is just so that the variable is more descriptive

The naming for task description would be better to be named taskDescription rather than just task.

The naming would be better set as lists rather than list. It is just so that it is more descriptive

Yes, I totally agree with kerkpy's input

Perhaps you can import individually and avoid wildcards, to be more explicit about what will be used.

This line exceeds 120 characters, I would suggest wrapping the line to improve readability!

Similar line length issue as above, and in a few other files too. Just need some line wrapping

It would help readability to have at least a javadoc header for each class! So the reader roughly knows what the class is for

Good to see a comment explaining the method. I think it would be better if they are written in javadoc format like

'''

/**

Prints introduction of klaun. This method is mainly called when the bot starts up.

'''

Similar comment as above regarding javadocs. Here's a suggestion for methods with arguments

'''

/**

Adds the task to the task list and prints a confirmation message upon success.
@param task The task object to be added to the task list.

'''

sick logo!

This is an interesting approach to initializing Duke. Is there a reason why you decided to use a static method, Duke.startDuke() to start the program instead of new Duke()? Just curious!

Yeap I agree, the methods are really well named. They are self-descriptive

Nice line wrapping

I think the this keyword is not necessary since there is no argument using the same name. There is a chance it might add complexity to the readability if there are many of such this planted throughout blocks of code in my opinion

Perhaps "YYYY-MM-DDTHH:MM" can be another readableFormat for parseIso just like how "DD MMM YYYY HHMM" is one for parseString. Just for consistency!

I like the splitting of import chunks, very readable. Shall do that for mine too

I think split as a method name might be confusing since there is a splitTime method too. Perhaps adding some javadocs description might help, or making this method name more explicit

I think it might help readability to split this into a few lines, even if it's slightly extra overhead.

Ahhh I see

Perhaps can include header comments for all public classes and methods, however I understand that this may not be included yet for the project.

Any reason why do you choose to use if-else statements over switch-case over here?

Perhaps can consider calculating intermediate values in steps to improve readability for complicated expressions.

Yes, perhaps a more descriptive method name such as loadFile, etc, might be better.

Perhaps giving more details to the method name would be better, such as writeToFile, etc...

name should accurately reflect the method as per coding standard. Do you think it is better to rephrase to "showAddMessage"?

naming here might not be intuitive at first glance to the reader, it may be better to add more context or description to the method name.

Minor grammatical error, perhaps can rephrase to 'Class to represent ...'

Minor grammatical error, perhaps can change 'initialized' to 'initialize'

It would be good to have header comments for all your public classes and methods. However, I understand that this may not be included yet for your project.

Perhaps start with "Runs" instead of "Run" as specified in the coding standard. There should also be a empty line between description and parameter section. Punctuation behind each parameter description can also be added to follow the JavaDoc comments coding standard form.

There can be an empty space between the description and parameter section, I noticed this in the other sections too.

Method header comments should start in the form "Deletes..." Perhaps can make it consistent throughout.

I noticed many of your methods are private and i like that there is a conscious effort to make them private, that is great coding practice 👍

I like how you included line breaks for long String value, improves readability. 👍

It may be better to add a newline at the end of your files to follow standard conventions.

Perhaps you could use another naming that could show better that it is a multivalued variables e.g. commandWords ?

Perhaps the description for the JavaDoc comment could end with a period, to follow the coding conventions. I think I noticed this for other methods as well.

Perhaps could remove this if it is not necessary, since there is a default constructor?

Perhaps you can use verbs to name the methods?

Perhaps this could be named as isDone instead?

Perhaps the description for the @param should also end with a period, similarly for other JavaDoc comments

Perhaps you can use a verb for the method name instead?

Perhaps you could use a verb to name the methods? I noticed the same issue for other methods as well.

For the JavaDoc, should there be a spacing between the description and the @return section?

Maybe there can be just one line of spacing between the two methods for a neater code?

Should there be a line spacing between the description and the @param section? And the second description could end with a period as well.

Perhaps there could be more information to when DukeException is thrown, although I'm not sure if it is a necessary thing to add

Should line 29 be removed so there is no spacing between the documentation block and the method?

Should line 52 be removed so that there is no empty space between the documentation block and the method?

For line 24, should there only be one spacing after tasks?

Should this be named in camelCase instead of all uppercase?

I think can add javadoc to explain what the class does and perhaps change the name to more specific like "AddTask", I noticed the same issue in several other places too.

Perhaps can start with a verb like "Adds a task" that explains what the method does?

I think the javadoc comments can be placed right before the class declaration instead of at the start.

Perhaps can change the name to formatDate to be more specific

Perhaps this method can be more descriptive and rename to getTask

I think this part explained the purpose of the code really well

I think there should be a line of space between the comment and the @param

I think the javadoc is missing a description

Perhaps this part can be removed?

I think can further add that it is a list of tasks with matching keywords

I think that it can be renamed to exitProgram for a more intuitive understanding

I like that there is test involving the file location

I think the method can rename with more specific description such as loadsData for clarity. I noticed the same issues in several other places too.

I think this is good naming

I think can rename to hasExited

I think can include a javadocs explaining what causes the exception to be thrown.

Perhaps can be more specific to what data/situations this exception would appear?

I really like how you are so specific with your exceptions, and how you've organised them all into an Exceptions package! Definitely learning from this!

Perhaps could explore regex as an extension so that your input can be slightly more flexible?

I like how your constants are cleanly organised at the top!

Maybe you can consider the Command pattern to handle the user commands, so some of the string output responsibilities can be abstracted out?

I really like how you abstracted out all logic regarding dateTime formatting to this Class! It even handles valid formatting!

Perhaps a more apt method name would be getSaveString()?

I really like how you're also testing your exceptions! But perhaps you could also include some test cases for normal expected inputs?

Nitpicking here but this javadocs you can replace with your own!

Perhaps a name like getSaveString() would be more intuitive?

Perhaps these values could be obtained directly from the Choice Enum class like here! That would mean less updating 👍

Perhaps instead of using the full input for each task, you could consider using the parser to prepare the input accordingly? Cos I noticed you work with substrings within the individual task methods, causing the taskList to be quite lengthy! So yeah perhaps some of that data processing responsibility can be abstracted to the parser?

Agreed! It's clean!

I'm not entirely sure but I think IOException might be a possibility here too!

Perhaps these strings could be abstracted as constant variables at the top of the class? Would be easier to edit and cleaner too!

I like that your code is decoupled and easy to test!

Actually, since you have already overwritten the equals method in your Todo/Deadline/Event, wouldn't the checks for them being of the same instance be handled in the overwritten equals method? I'm not 100% sure and may be wrong here.

The variable name looks fine here with the LocalDate type specified right before it, however, it may be less obvious in other parts of the code where the type of by isn't immediately obvious. Maybe a more descriptive name here might be better?

I like that you have specific exceptions for a possible error the user might run into 👍

Would it be better to extract the templating part into a helper function such that you can change it once for all exceptions if needed?

This part is very neat and concise 💯

What is Customer here?

I feel that a method name of markDone might be more consistent with the namings you have used in Parser which was markAsDone.

The spacing here makes the code readable but I feel that this might be a complicated expression that is hard to follow through without additional context.

Hey, I've noticed the package names all begin with a capital letter but our coding standards require it to be in all lowercase.

Hey, the variable names for the parameters along with the javadoc comments don't seem to give much information regarding what the function expects. I see that the classes extending this one have more specific comments and variable names which is great! Perhaps this could be made more descriptive?

Hey, class names should be written in PascalCase so the first letter should be capitalized here.

I've noticed this in other places as well but perhaps some variable names could be longer to give an indication of their purpose? In this case maybe the 'done' variable should have been the 'String' which might help in reading through the code.

E.g.

'''

char d = current.charAt(4);

String done = "";

done = done + d;

'''

This might help in the latter parts when referring to what the variable means.

Hello, according to the coding standards, boolean values should be named to sound like booleans. An alternative here could be isDone

I like the simplicity here 👍

This method seems quite long and is doing a lot of things. Maybe it could be separated into smaller methods which handle one functionality each?

This code seems to be repeated in a few parts, would it be better to have your Parser class handle some of these parsing?

The naming of this variable might make it seem like it is an action and can be called.

I like the clean code here. Is it perhaps better to rename the variable "by" to something clearer?

Good usage of OOP principles!

Shouldn't there be no indentation for case clauses?

Is there too much usage of if-else loops here?

Should there be a white space character after 'for'?

Shouldn't there be no indentation for case clauses?

Is line 35 (blank statement) removable?

Perhaps you can consider using the following naming format "whatIsBeingTested_descriptionOfTestInputs_expectedOutcome" for your test cases?

Perhaps you could include more comprehensive test cases?

Great idea to abstract the Ui class.

Clear implementation.

Is it better to simply name the variable 'index' instead of 'idx'?

Impressive implementation! Although there are many lines of code, it is still very readable.

Perhaps you should resolve this issue before you finalize your product?

Perhaps naming the variable as 'index' is clearer?

Should there be a whitespace before the braces? Similar instances in other classes.

Perhaps the variable hasEnded can be private?

Perhaps remove indentation for switch case, as according to the module formatting guide?

Possibly remove the class if it is not used, unless it will be used in the future developments?

Could arrange imports by lexicographical order?

Operators could be on the new line. (Other instance below as well)

Splitting up the line here could help with readability, since it is over the char limit.

Perhaps more whitespaces would help readability here?

I liked the clean abstraction of all the methods and classes, keeping the main class concise and neat.

Could consider using a clearer name like "TaskList" instead?

Could either use final variables, or remove the all caps from the string names?

Rearrange the fields in order of access modifiers?

What happens when the user tries to create a dateline without date/time? Perhaps could show a custom error for that?

Maybe placing this case breakdown in the Parser Class could be more suitable, and just return the output message (with any possible errors)?

Perhaps saveTasks (similar to loadTasks above) or saveTaskList would be clearer in reflecting the methods usage?

Maybe just using input.equals() will be clearer since it is only important to check equality and sorting is not required?

Perhaps a more boolean-ish name like "isCompleted" here?

May I know why you chose to put "time" into the Task class instead of just the Deadline and Event since Todo does not require "time"?

I like how these tests covered a wide range of inputs!

I like this design as it is very readable

I like how you designed this part of the code. I feel that it is very unique for the method to return a boolean to tell the application to continue running and at the same time give the required outputs to the user.

I like how you test for end cases

I agree

I think that the current way is fine and I actually like it more

Perhaps there is a way of changing your code design so that you can initialise with just one line of code instead of calling the constructor twice?

Perhaps you can put your comment on top of the line of code instead of beside it?

Not really sure if this violates Java coding standard.

Should this be extracted out? Any reasons why you chose to have the input processing method in Duke.java instead of a separate class?

I like how you named this member. It is very clear that its going to be a boolean!

I agree

Yes public classes should have java docs if possible

May want to handle cases for when the user mistypes.

For example Tood would also be treated as a todo

Yes single letter variables should only be used in loops.

try to avoid using single letter variables outside of loops

try to avoid using single letter names for variables

For example, this chunk can be split into a different method just for returning if the cases is deadline

Should expand import statements to allow for easier debugging

static variables should be in all caps

Looks fine but maybe using String.format maybe better here?

IsExit maybe a better name?

exit sounds like trying to make the progamm exit

Method is a bit long, it maybe a good idea to split the method up to make it easier to read and debug

n isnt a good name as it is not obvious what it represents, try using a name like numTask

static names should be capitialised

static names should be caps

Expand import statements

Expand import statement

The "+" should be in the next line instead.

There should not be a spacing between "i" and "++".

I have noticed that your Duke class may have too many methods (a little cluttered), and seeing that you have not merged "branch-A-OOP" into master, I am not sure whether you have create new classes to adhere to OOP principles?

A better practice might be to split the instantiation of "lst".

After your import statements, it could be List lst;

Then in your Duke constructor: this.lst = new ArrayList<>();

It might not be too good of practice to use "while (true)", as it is hard to tell what is your terminating condition (and there is a chance of an infinite loop)?

A spacing after "Exception" will look nicer!

Same as mentioned in DukeException class.

It might be better to use Enum to represent 1 and 0, as it might look like "magic numbers".

Maybe it would be nicer if you leave a line after package for your static import.

I think you forgot to fill in "@return ..."?

The public class and its methods are missing the JavaDoc.

The custom DukeException should have JavaDoc too, to describe briefly what it does?

The param "s" could perhaps have a more meaningful name, like "description"?

Same as mentioned in Deadline class.

I think this is still a work-in-progress right?

You might need a JavaDoc here as it is a public class.

Instead of calling the same method twice, maybe you could assign the result of description.split() to an inputArray and get the task and by calling inputArray[0]/inputArray[1]?

Could you have just indented the return string by one line instead of four?

Why not just throw the specific number format and index out of bounds exceptions? Just curious!

Very clean use of switch case! Nicely done, Something I can learn from!

The naming of the method can be more descriptive! For example, loadTasksFromFile().

Any reason why you indent short lines of codes? I noticed this in several other places too.

I have noticed you use "output +=" in many of your codes above. Could this be done within "tasks.get(...)" itself?

Perhaps you can write javadocs for this class?

Should these methods have javadoc comments? ... I noticed the same issue in several other places too.

Is there a need to create a method for opening and greeting text? Can they be static attributes?

I'm not saying it is wrong I'm just curious 😃

You did your exceptions EXCEPTIONALLY well. Very impressed! Something I can learn from. Thank you.

Do you need to leave a space after you JavaDoc comments?

Very interesting! I threw an exception here but I think your idea is good too.

You can try using switch case to compare keywords here! It will help to reduce your code and make it look neater too. Also with switch case, you can omit the methods such as isDelete, isFind... etc.

Is it also possible to bring out some of the if statements too? Because I see many recurring if statements in the method.

Should you remove comments that are not descriptions? These comments are from your old iteration of codes.

Perhaps you could remove this comment?

Coding standards suggest that verbs should be used to name methods. Perhaps changing textToTask() to getTextToTask() instead?

Similar to textToTask() method, may want to consider changing newToDoT() to getNewToDo() or createNewToDo().

At first glance, I'm not very sure what this method is deleting. Perhaps renaming the method to deleteTask() would make it clearer as to what you are deleting?

Naming standards suggest that we should use names to explain and distinguish between methods and variables. I'm not very sure as to what you are trying to test just by looking at the names of the test methods. It may be better to explain what each test does in its name.

JDocs guidelines recommend starting header comments in the form of Returns (instead of Return or Returning). Perhaps rephrasing the header comment to 'Handles commands that adds deadline'?

Coding standards suggest that all public constructors and methods should have Java Documentation. I noticed in some classes you have added the JDocs for the constructors and methods while for other classes you did not, did you perhaps forget to add JDocs when refactoring or you ran out of time?

Same comment about Java Documentation for AddDeadlineCommand.java. JDocs guidelines suggest header comments be in the form Returns (instead of Return or Returning). I noticed this issue in a few of your other classes as well, could it be due to a lapse in memory when refactoring your code?

This is just personal preference but it may be better to import all the relevant Command classes at the top to make things a little easier to read.

Eg: Instead of 'src.main.java.duke.commands.AddTodoCommand.MESSAGE_USAGE', import the AddTodoCommand class above and store 'AddTodoCommand.MESSAGE_USAGE'.

I like how you stored all the static constants in a single class. Good job 😃

JDocs guidelines suggest a space to be an empty line between the description and parameter section.

Similar to the above comment, JDocs guidelines suggest there be an empty line between the description and parameter section. There are similar issues that occur in other parts of your code too.

The method throws an exception but in the method body, no exception is thrown. Is it possible for a method that throws an exception to not throw an exception in the body?

Boolean variables/methods should be named to sound like booleans. Perhaps changing contains(Task toCheck) method to doesContain(Task toCheck) instead?

I like how you have organized your import statements. Very neat and easy to read 😃

I like how you have constant static variables to indicate the format for each task. You could perhaps consider changing the constant static variables to private instead as it appears that these constants are only used in Parser.java. Otherwise, nice job.

Missing @return tag in JDocs

Maybe you can avoid complicated expressions like this if statement by adding calculating intermediate values first? For example, add a method that checks if the task is created with no description.

Similarly, maybe methods can be added to calculate the intermediate values first for this statement? For example, methods to check if the input contains "done" or "list".

Maybe the expressions can be less complicated by using methods that will get intermediate results? For example, a method that return 1 if the task is done, 0 otherwise.

Maybe you can consider removing the "else if" and using "if" instead, to make the happy path more prominent?

Maybe a named constant for this string can be added to avoid such magic string? For example, you may add a constant called LINE_DIVIDER.

Maybe the magic string "Nice!.." could be avoided by adding a named constant for it?

Maybe the magic string "| 0 | " and "| 1 | " can be avoided by adding named constants for these strings?

I think maybe the string "T" can be abstracted by adding a constant to represent it, which may make the code easier to understand?

Maybe the Ui.print(...) part can be further abstracted by adding a method for example, Ui.printAddition(task) to enforce a same level of abstraction in the method?

Should Javadocs be added to this class?

Maybe the boolean variable can be renamed to sound more like a boolean, for example, name it to "isCommandFound"?

Should Javadoc comments be added to this public method?

Should the empty line between the two sentences be deleted according to the coding standard?

Should the boolean method be renamed to sound more like a boolean method, For example, "isTaskCompleted" or "hasCompletionFlag"?

Should the boolean method be renamed so as to follow the coding standard for boolean methods, for example, "hasSearchTerm", as the method is to check whether searchTerm is contained in a description?

Should javadoc comments be added to this method?

There should be no indentation for case clauses for CS2103 convention.

Minor issue, unused variable.

I like how the import statements are organised based on their association 👍

I notice other files have the line to separate package and import statements except for this. Would be good for readability to standardize according to src/main/java/duke/logic/Storage.java

It could be the files that were written earlier that result in the inconsistent ordering of import statements.

Variable name should be in camel case and underscore should only be used for separation for constants.

I notice that this appears quite regularly in other files too, do clarify on this if necessary!

Can consider unformattedDateTime instead of unFormattedDateTime as "un" is not really a standalone word

Might be a typo here for unknowncommand, should be unknownCommand instead

I really like the way you write your code, this is just a minor point that I would consider as nitpicking because your naming is really too neat.

Could consider renaming listOfItemsInString as listOfItemsAsString or instead because it's the items within the list as a string instead of being within the string.

endGreeting can be misleading as part of the greeting message, can consider using farewell or closingMessage to be more explicit.

Missing package. Every class should be part of some package according to convention.

I like that some of your @param and @return contain the type, could try to include some simple description like @param commandType Command from user input.

Not sure if it's meaningful to include params if it's self explanatory.

I agree, actually it is possible to keep the names concise like EXITDUKE could be understood the same way as EXIT, the ADD and TASK within the names could be removed and still be interpreted in a similar manner. There is nothing wrong with keeping your names explicit but it would have to follow the naming convention as mentioned by Siddarth above.

Is this meant to be hard coded for formatting purpose?

Should a blank line be present here between the 2 import statement?

Perhaps the @throw exception is missing or the method does not actually throw the exception?

Maybe a JavaDoc can be added here to explain why we need an overloaded constructor?

How about making this variable private?

I like the error handling for the delete command. Maybe the JavaDoc or Exception message can mention the case "task being deleted does not exists" refers to the case where the user types in a number larger than the size of the list.

Should this method be an overriding method?

Perhaps I would prefer a more informative naming for this variable such as "deadlineTime".

The utility of by and date seems to be overlapping here, maybe you the usage of String by can be completely avoided.

Perhaps this is also an overriding method? I noticed the same issue in several other places too.

May I know why the variable accessibility is protected? Is it possible to make it private instead?

Also, the naming of this variable may be changed to something like "taskToFind" to make it more informative.

Perhaps the conditioning can be changed into switch case for a clearer picture?

I like the use of lineSeparator method. Very convenient!

Anything to put in the else clause here?

Maybe you can make the method naming longer? I feel that generateList and itemsList are much clearer even though they are longer.

Hi, I don't think using wildcard imports is better. The following line can be found in the CS2103T Java coding standard:

Imported classes should always be listed explicitly.

Perhaps this could be rewritten to be in line with the coding standard?

In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)

Consider adding header comments for all public methods as suggested in the style guide; there are a few public methods which do not have comments.

Should the imports be listed explicitly instead?

Perhaps a more descriptive variable name could be used since the scope of this variable is not that small? Same for some of the other one letter variables.

Would it be possible to rewrite this as a verb?

Should an empty line be left between the description and parameter sections?

I believe that the coding standard states that case clauses should not have indentation.

Should this documentation block be moved down to right before the class?

I like your use of a guard clause here! It makes the happy path much more clear.

Consider breaking this method down into smaller methods.

Be wary when a method is longer than the computer screen, and take corrective action when it goes beyond 30 LOC (lines of code). The bigger the haystack, the harder it is to find a needle.

Perhaps this expression can be done in steps instead? I noticed that you have fairly complicated expressions across your other Event classes too.

Avoid complicated expressions, especially those having many negations and nested parentheses. If you must evaluate complicated expressions, have it done in steps (i.e. calculate some intermediate values first and use them to calculate the final value).

The parameter description appears to be missing @return.

Would it be possible to rely on polymorphism instead of checking instanceof for each event type?

Consider changing this to the more boolean-sounding isCompleted.

The indentation here should be 4 spaces.

What is the purpose of having 2 functions that mark a Task as done?

Constant names should be all uppercase using underscore to separate words.

You should break before an operator, not after.

Your boolean should have a more descriptive name.

You shouldn't use wildcard imports.

Try using more descriptive names for your variables.

This variable name seems hard to read, perhaps you should choose another name?

Is there a reason why you're catching exceptions in your test? Are you expecting your input to throw an exception?

You seem to repeat this cycle of showing a line, printing stuff, and showing another line a few times. Perhaps it should be extracted to a function?

Instead of creating the Todo and then marking it as done, perhaps you could just create an additional constructor so that you can define the isDone boolean on creation.

Should the parsing of tasks be handled by the Storage or TaskList class?

This function seems to be parsing the command, should that be the responsibility of the Parser class?

Instead of manually processing the date/time, you can use built-in Java libraries to do so.

This logic seems to depend on the done command only having 4 letters. What if the done command changes to another word?

Perhaps these classes could be imported explicitly? It will make your code easier to comprehend and maintain

I agree with using an underscore to separate the words here. Gives better readability

Perhaps you could add whitespace immediately after the brackets here.I noticed this issue in other areas as well but I believe this was just an oversight on your part.

Agree with luo yi here. Could have placed else if directly after the preceding bracket on the same line to adhere to the style guide. I've noticed the issue in other areas as well, but this should be an easy fix.

Same sentiments here, perhaps you could have run your code through the style checker again. It will help identify small mistakes like this.

Since this is a String array representing "commands", perhaps the plural form of command could be used instead.

Perhaps you could try to short this run method? It seems to be longer than 30 LOC which could make it difficult to debug. Just a suggestion.

Perhaps you could try to avoid further deep nesting here? There are already 3 levels of indentation. If you could cut down the levels of indentation further, I believe your code will be much clearner.

Perhaps you could rename the encode() method in order to explain it's purpose? For example, maybe encodeDateFormat() would be a more descriptive way? Just a suggestion.

I like the use of a verb for this method. It helps to make the purpose of the method clearer. I also see good use of nouns and verbs for classes and methods respectively in other areas, so keep up the good work!

Perhaps you could add javadoc header description for overriding execute methods? After all they are still public methods. I noticed this lack of description in other areas as well.

Perhaps Duke could have some descriptive header comments? If I am not mistaken, we are required to have header comments for all public classes

Perhaps you could add Javadoc header comments for the main method? Again if I'm not wrong, we are required to have header comments for all public methods and classes.

Perhaps you could add Javadoc header comments for this overriden method? I've noticed this minor issue in other areas as well.

I like your adherence to the naming convention here for the boolean isParse! Usually these small naming conventions would be an oversight for most people.

Just a slight nit pick! I feel that while the factory method names are mostly self explanatory to those familiar with the Ip, it might be better if you included javadoc comments explaining when such exceptions will be thrown.

Perhaps this javadoc comment is better off written above the interface declared at line 12?

Maybe "constant" would be more appropriate as there is only one constant!

Nitpicking again, but is res a good variable name for your list of tasks? Perhaps a more intuitive name such as taskList would be better!

I think you missed out a space between these methods

Should it be "method" instead of "methods"?

Another nitpick! There were certain groups of methods that were separated by an empty row and some there were not, such as these constructors, even though the methods were part of a certain category. Perhaps this could be standardized?

Missing javadocs for public methods.

This issue also appeared in multiple other areas as well.

The method name is not very clear! Perhaps you can consider "outputTaskList" ?

Small nitpick, but I feel that getBy() is a rather confusing method name. Perhaps you can consider dueBy() or getDueBy()?

Another nitpick, perhaps a clearer name could be given to the StringBuilder object, such as "stringBuilder".

Another nitpick, while listTaskSize isn't a bad method name given its function, perhaps a more appropriate name could be numberOfTasks() or getNumberOfTasks()?

Nitpicking again! "newTask" could be a little confusing considering we have 3 unique types of tasks. Perhaps consider "event" instead?

Same nitpick as before. Perhaps consider "deadline" or "newDeadline" instead of newTask!

Perhaps you could rename 'expected' to 'expectedOutput'?

I think the ASCII cat is really cute 👍 Maybe consider changing the variable name to all uppercase because it can be treated as a constant?

I like the use of an enum to keep track of valid & invalid formats. Much better than using integer status codes. Perhaps these should be in uppercase as it is an enum? I noticed a few other variables in a similar position.

I think enum names should be written in PascalCase based on the coding standard? 🤔

Would it be possible to avoid wildcard imports?

Maybe add a space character after while?

Should this be in camelCase instead?

Do you think the nesting may be a bit deep here? I tend to find nested if-else hard to read when it goes down to 3-4 layers. One possible way of avoiding this:

'''

if (taskList.isEmpty()) {

ui.display("UR LIST HAZ NUTHIN LOLOL");

return; // Stop the rest of the method from executing

}

if (by.isEmpty()) {

/* continue from here */

'''

Maybe the this keyword can be removed?

Perhaps the boolean name could be more descriptive here? Also not sure if it is intended but could you check if b is needed? Seems like it is passed in as a parameter but is not used in the method itself.

I think there was a small typo here: Return instead of Returns.

I think there is a minor typo here: tasl instead of task.

Do you think using a verb for the method name is better? For instance, openFile() or createOrLoadFile() (longer but more descriptive) to indicate that a file will be created if it doesn't exist, or loaded if it exists.

I think fileCheck() doesn't sound like the method is loading the state from the save file.

Perhaps the name index can be used instead of i to show clearly that this is not an iterator variable?

What do you think of using the variable name count here to differentiate between the index of the task list and index of the matching tasks?

Since there are so many similar methods, do consider extracting them into a separate CommandChecker class. I think that would help keep track of the commands. The current setup might not scale as well if there are more valid inputs that you need to check against.

An alternative might be to use a single checkCommand(String s) method that returns an enum. This solution would allow you to switch on an enum instead of a boolean, which might enhance the readability of the parse(TaskList taskList, Storage storage, String text) method.

I think according to the Java coding standard guide on the CS2103/T website, under the layout section, it says that there is no indentation for the case clauses. Hence I think to avoid any coding standard violation, it would be advisable to fix the indentation for all of the case clauses to follow the guide.

According to the Java coding standard guide, under the Naming section, it says that boolean variables/method should sound like booleans. Should this be boolean isStop or boolean shouldStop instead of boolean stop?

According to the Java coding standard guide, under the Naming section, they mentioned that naming of constant variables must be all uppercase using underscore to separate words. Hence should this be private static ArratList<Task> TASK_LIST instead of private static ArrayList<Task> taskList?

According to the Java coding standard guide, under the Layout section, I think it shows a sample formatting of a switch statement and in it, there is no blank newline after the break. Should there be a blank newline after the break in the following code?

Should there be whitespace in-between Duke and {?

Should there be whitespace in-betweenDukeException and {?

I think according to the Java coding standard guide, under the Layout section, it says that line length should be no longer than 120 characters. Should the String in the System.out.println maybe be wrapped to avoid such a coding standard violation?

According to the Java coding standard guide, under the Naming section, it says that boolean variables/method should sound like booleans. Should the variable name be maybe renamed to boolean doesDirExists or boolean isDirExists instead of boolean dirExists?

I do not think this is a coding violation but I think a way you could try to implement to shorten this code would be to return commandType.equals(CommandType.EXITDUKE). This would just be a suggestion to shorten the code and make it simpler for others to read as well.

There is no coding violation here but would it better if you change the multiple else-if statements to a switch statement and handle each different case within the switch statement? This might help to improve code readability and make the code even cleaner.

According to the Java coding standard guide, under the Naming section, it says that constants should be all uppercase using underscore to separate words. Should there be an underscore between variables with multiple words in it? For example, EXITDUKE could instead be EXIT_DUKE?

According to the CS2103/T textbook, under the "Guideline: Name well" section in the Code Quality chapter, it says that nouns should be used for classes/variables. Maybe you could consider using a noun to describe your variable. You could maybe use deadlineDate or dateTime instead of by.

I do not think this is a coding violation but I think a way you could try to implement to shorten this code would be to return symbol.equals(icon). This would just be a suggestion to shorten the code and make it simpler for others to read as well.

Should there be a line between package and import statements?

Perhaps use the featureUnderTest_testScenario_expectedBehavior() naming format for test methods for greater readability.

I like how comprehensive your testing was.

I agree, there should be a javadoc here since it is a public method

Is the 'this' keyword necessary here? The userTasklist variable is not shadowed by any constructor parameters here so I think it may be better to leave it out as per the coding standard guide. I noticed this is some other parts as well.

Maybe use a longer/more descriptive name for err parameter eg. error.

Should there be a javadoc description for the class? I noticed this in the other classes also.

Should there be a javadoc description for this public method? I noticed this in the other methods also.

Perhaps the 'done' parameter should be renamed to 'isDone' to make it sound like a boolean. I saw this is some other methods as well.

Is the 'this' keyword necessary here? The date and time variables are not shadowed by the constructor parameters so maybe it would be better to leave them out as per the java coding standard. I saw this is some other methods as well.

Would it be better to make "[✓]" and "[✗]" named constants to avoid using 'magic' values?

Maybe 'e' should be renamed to something more descriptive, eg. 'error'

Should there be a line between the package and import statements?

I like how comprehensive your testing here is!

I like the clear naming of the testing methods!

Perhaps it would be better to use a more meaningful name instead of s for the String?

Maybe it would have been better to leave a line between your import statements and your javadocs?

Would it have been better to use a clearer name for a boolean such as isParseDone?

Is it better to use another way to name your boolean such as isParseEvent?

Perhaps it would be better to break before the "+" operator to improve readability?

Perhaps it might be better to separate the import statements into their categories to make it neater?

Maybe it would be better to leave a line between your imports and javadocs? Might be better to standardize throughout your code.

Maybe it is better to call this method getTaskList() instead of getList() since it could be confusing as some may interpret it as getting a List object instead of the TaskList object.

Perhaps it is better to name your TaskList object as taskList instead of list to avoid confusion and make it clearer?

It could be better to name this boolean as isEqualTo instead of equals.

Method seems to be pretty long, more than 30 LOC, perhaps could try to simplify it?

I like how you break the line to avoid a line that would have been too long. 😄

I like this block of code, very neat layout of if/else! 👍

Perhaps you could name the method clearer, like printList, to indicate that it is printing a list.

similar to the comment above, you could rename this method to indicate that it is printing a list.

Good practice of keeping the same level of abstraction! 👍

datetime should be in camelCase?

Final int should be in all caps?

Extremely long if else command with nested commands hinders the overall awesome readability of the rest of your code 🤔 Would there be a method to reorganize this?

I've read somewhere that instanceof is not ideal for checking class identity -- perhaps there is a better way to approach this?

It might be better to list out the specific libraries that you are importing instead of importing them all with *!

This boolean might benefit from a clearer name e.g. isSuccessful

Again, listing out your imports individually will reduce loading time!

It is an array of multiple items, so maybe a name indicating its plurality might be better? e.g. stringParts

I believe Class name should be singular, so you might want to rename Todos to Todo!

Same thing here with Class name being in the plural form!

Name might benefit from more description e.g. deadlineBy or deadline

Hmm I feel like this package could have a clearer name, since tasklist doesn't fully represent a comprehensive view of your application 🤔

Again class names should be singular!

Unnecessary?

Missing return tags for javadoc comments

Found the following in a javadoc article

"Omit @return for methods that return void and for constructors; include it for all other methods, even if its content is entirely redundant with the method description. Having an explicit @return tag makes it easier for someone to find the return value quickly. Whenever possible, supply return values for special cases (such as specifying the value returned when an out-of-bounds argument is supplied)."

https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#@return

line 21: Please try to keep the line character length to 120 characters (currently 130 chars)

line 33: line character length of 120 chars, consider wrapping the line for better readability

Missing javadoc comments for the following public methods: getDone() and getTaskName()

Consider line wrapping for better readability, there might be cases where a developer has to review/debug this file

Minor nit: Missing whitespace between DukeException and {

Missing javadoc comments for the following public methods: getUserDialog(String text, Image img) and getDukeDialog(String text, Image img)

Missing javadoc comments for the following public methods: getType(), getIndex(), getName() and getDate()

Variable names are nouns and boolean variables are boolean sounding, good job!

Methods are named with verbs and provides sufficient insight into what they do

Perhaps showAddTaskMessage, showDeleteTaskMessage and showDoneTaskMessage would be more descriptive and less ambiguous

Missing return tag in javadocs

https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#@return

I think Parser is a suitable name for this class because its function is to decode user input and convert it into Commands!

I like your storage formatting! 👍

Would it be clearer if this variable was named something like dateTimeString? Same for Line 126 😃

I think naming constants as @sigmund-c suggested is compliant with coding standards!

I like that you check for many possible date formats! 👍

Perhaps a better name for this variable could be dueDate?

Perhaps a better name for this variable could be eventDate?

I think according to the coding standard, enum names should be written in PascalCase!

Should there be a space after DukeException? I've noticed this issue in several other places too.

Should this method be named as a verb? I've noticed this issue in several other places too.

Should non-constant fields be written in camelCase instead?

Should enum names be written in PascalCase instead?

Should try-catch statements be formatted in the following manner instead>

'''

try {

statements;

} catch (Exception exception) {

statements;

}

'''

I like how clean this bit of code is! 👍

extra blank lines?

Maybe you can start with "Represents..."

is there supposed to be anything?

can add javadoc comment for class

The indentation seems wrong...

Same here

The indentation here should be 8 spaces to the right of the previous line I suppose...?

There is extra space

Maybe you can consider changing "keyword" to sth like "commandType"?

I feel that this line is rather long...

I think the blank lines may be unnecessary?

Maybe can considering wrapping these three lines into one, 'cause it does not seem complicated to me 😃

I am not sure about this but I want to point out that the variable names generated from abbreviation may be confusing in some ways. For example, "fos" makes me think of faculty of science... I think it is acceptable to write in this way, but I believe use complete words can reduce confusion (such as fileOutputStream)

More indentations than should be? 😃

Perhaps it will be good to include a Javadoc comment for this method?

Perhaps we can combine the comment into one line to make the comment more succinct?

I noticed this is a repeat of the earlier issue. Perhaps we can combine the comment into one line to make the comment more succinct?

Perhaps we can add a comment for this method about what it should do even though it returns an empty string? (ie what is it supposed to be used for in its children classes)

Perhaps it will be good to add the @Override tag here? (So that compiler can check if overriding is done properly!)

Perhaps we can change by to dateBy to make it more intuitive?

I think constructor should be capitalised (Constructor). I have noticed this in other classes' constructors as well.

I think it'll be great if javadocs can be added to summarise the interface's functionalities?

I think it will be better if we standardise this to showErrorMessage as per the other methods?

Perhaps this should be a verb, such as printUnknownCommandMessage?

I think for some of the methods used by Ui should be changed to verbs form, such as printGreetingMessage.

I think this method name can be changed to markAsDone? (Present tense verbs)

I think it'll be better if a default case can be added to handle exceptions?

I think for line breaks, the operator (such as +) should be in the next line!

Perhaps you can write Javadoc comments for public classes? It is stated in the style guide.

I noticed this in several other places too.

Perhaps you can write Javadoc comments for public methods? It is stated in the style guide.

I noticed this in several other places too.

Perhaps 'this' is unnecessary? The basic coding standard doesn't require this, but is suggested by the advanced style guide.

'''suggestion

        date = LocalDate.parse(by);

'''

I noticed this in several other places too.

Perhaps you can name your variable to a noun instead of using a scratch variable as stated in the style guide.

'''suggestion

String userInput;

'''

Plural form should be used on names representing a collection of objects.

'''suggestion

    ArrayList<task cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\ip-review-comments-panels.mbdf"> listOfTasks = list.getTasks();

'''

The description of parameters should be included. Similar problems are found in other places.

Maybe the name can be changed to 'strings' instead?

'''suggestion

                String[] strings = command.split("/at ");

'''

Perhaps you can add an access modifier?

Perhaps this line break can be omitted? I noticed double line breaks in several other places too.

Perhaps 'this' is unnecessary? The basic coding standard doesn't require this, but is suggested by the advanced style guide.

'''suggestion

    filepath = Paths.get(System.getProperty("user.dir") + filepath);

'''

I noticed this issue in several other places too.

Should there be a line break before describing the parameters? Noticed that some methods have a line break while others do not have.

I like the use of the scratch variable s since the variable is used for temporary storage only. 👍

Perhaps the brackets can be omitted?

Maybe this can be deleted?

Perhaps it can be started with an action word e.g. returns?

What do you think about "Loads tasks in tasklist.txt file into the TaskList if the file exists"?

I have noticed the same issue in several places too.

Perhaps it could be ended with a full stop to be consistent with the coding standards?

I have noticed the same issue in several places too.

Perhaps the naming of the method could be improved?

The method name suggests to me that a "bye" response is printed and that it is a void return method instead of a String return method.

I have noticed the same issue in several places too.

Perhaps the + sign can be moved to the current second line of String to be consistent with the coding standards?

Perhaps it may be good to set the Map object as an attribute of the Bot class?

Perhaps this code could be simplified for readability?

Perhaps the comment is not necessary as the code and comment indicates the same meaning?

Perhaps the naming for the method could be better, such as handleDeleteCommand?

Perhaps you could use Loads instead of Load to be consistent with the coding standard?

Perhaps the method can be <= 30 lines of code to be consistent with the code quality standard "avoid long methods"?

Perhaps there could be less deep nesting to be consistent with the code quality standard of "Avoid Deep Nesting"

Perhaps the ; could be in line 25?

Perhaps this comment is not needed?

One suggestion I can think of is to make the map an attribute, and abstract out the lambda as a method with a meaningful method name. That way the code would be much shorter and can be understood more easily and more quickly.

As this class is public, should there be a JavaDoc comment for this class?

Perhaps a more descriptive failure message could be employed here. For example, the message of the exception could be printed out. Otherwise, you could also consider using org.junit.jupiter.api.Assertions.fail instead of printing "Fail" to the console.

Similar to public classes, should there be JavaDoc comments for public methods as well?

Should this class belong in a package?

As this class isn't extended by any other class, would a private modifier be more suitable here?

Perhaps a more descriptive name for the test could be used here?

You could consider naming collections of objects by the plural of the objects they contain. In this case, would it be more suitable to name this variable, tasks instead?

I like the functionality of letting the user choose whether to input a duration 👍

As this taskNumber isn't accessed from other classes, perhaps you could consider using a private modifier?

Just a small nit, there should be whitespace after Task

Perhaps variables could be named more explicitly for readability? For example, File file instead of File f.

Perhaps it would be better to make this check clearer, like what does sc.nextInt() == 1 represent. Adding a comment above would also help readability.

Perhaps consider grouping classes into their individual packages?

Perhaps you could call saveTasks after every time the task list is modified instead of just when the user exits the program. This would ensure that the tasks are saved even when the program is closed incorrectly, e.g. by pressing the close button instead of typing "bye". However, this is only a suggestion for your consideration.

Should the starting word be creates instead of create? Same for the other Exception classes

Can consider including javadoc to better explain code.

Can consider reorganising the code so that it is easier to follow. Perhaps consider using switch statements also?

Minor detail but perhaps add a space before the curly brace? Same for other parts of the code.

It was a bit hard for me to understand this method initially. Perhaps consider adding some comments.

Is there any reason why you chose to have your Duke and Ui the way it is?

Currently my understanding is that all important functionality (reading from standard input, parsing the command and handling the logic) is in this Parser class. Perhaps consider whether this is optimal and more abstraction can be used?

Forgot to capitalise executes

Can reconsider naming of method so that method name starts with a verb instead of being phrased as the thing that is being returned.

Perhaps the description of the method could have been clearer? Can also summarise what the code does in the first sentence instead of saying what the code returns. Same for deleteMessage and taskLeftMessage.

Can reconsider phrasing to a description of what code does even though it would be general in this case

Perhaps reconsider naming of method

Can consider adopting a consistent grammatical style. So instead of saying Creates an instance of Duke, instance of ui created too. TaskList initialised. consider phrasing it as something along the lines of Creates an instance of Duke and ui. Initialises TaskList

Forgot to capitalise constructor.

Perhaps consider rephrasing the comment as it may sound Singlish.

I like how there are line breaks to improve the readability of the error message.

Perhaps a better comment is "Deletes a task."?

Should there be an empty line between the description and return section? I have noticed this at other places too.

Perhaps remove the indentation of the switch clauses? I noticed the same issue at other places too. Changing your IDE settings will allow for easier detection and reformatting 😃

Perhaps consider adding a toString method instead and pass the Strings as arguments? An example can be found with the Planet enum class at https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

Adding a Javadoc comment is suggested since this is a public method.

Consider leaving a space between the package and import statement.

Perhaps consider explaining what will happen if parsing fails.

Consider changing "Parse" to "Parses".

I think there is an extra space in the return description?

Perhaps consider renaming to SYMBOL_TICK and SYMBOL_CROSS?

Perhaps considering renaming it to storage as store can be interpreted as a verb.

I'm not so sure but should there be an empty line in between since both are from different dependencies?

I think you forgot to add an access modifier and JavaDoc comment for this method. 🤔

Do be careful when using valueOf as it throws a NumberFormatException if the string is not a number. Might be good if you add a try catch block to catch the exception and notify the user that the index input is not a number. 😄

using details[0], details[1] might be abit confusing. It would be better to give them detailed names such as taskType = details[0], taskName = details[1] and taskDate = details[2] to help improve readability. 👍

Missing a JavaDoc comment.

A nitpick but the JavaDoc should start with "Reads" instead of "Read".

Quoted from the Java Coding Standards:

"In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returning etc.)"

This class is missing a JavaDoc header. Its constructor is also missing JavaDoc comment.

JavaDocs for private attributes and methods are optional. But it is still good to include them. 👍

I think you forgot a JavaDoc for the main method 😅

It seems a number of your exceptions are missing JavaDoc comments. Do remember to add them to help users understand the code.

I like how you ensure that parseInt will not result in a NumberFormatException by explicitly checking for a number in the string beforehand

I think you can just use the exception thrown from parseDateTimeString so that the user knows how to recover from the error. The user might not know how to deal with the error if it only says that it is "corrupted" but on the other hand if the error is "Ensure the datetime passed in is of the form" the user can manually edit the duke.txt file if required.

It will be better to just standardize the save location. So if the directory does not exist, create it and just save the file to the same directory. This can help reduce confusion on the save location for both user and programmer.

Would be good to define what qualifies as equal in the JavaDoc comment. i.e both name, time and date must be equal.

Good use of StringBuilder instead of string concatenation in order to prevent constant duplication and minimize overhead 👍

Cool personality!

Perhaps this line can be explained?

Personally, this level of indentation feels too nested.

A comment explaining what is "\u2713" would be great!

Consider writing a comment on what this String array is supposed to look like

Consider commenting what these unicode characters are too 😃

Consider setting this constructor as private - I suppose this is called when setting a task as done? The method can be protected but the constructor itself can be private.

showWelcomeTaskList can make use of showTaskList() for ease of change in future, or it might be better to collapse it into a single method since they are somewhat similar.

Agreed

Remember to remove methods that are no longer needed

Yes, consider shifting the method to Task class instead

Perhaps it would be great if there are some comments on how the parsing is done

For this segment, consider using the return String from greet() and printing it in showWelcome()

Perhaps giving a comment on the expected format of the input (so that contentParts[0] and contentParts[1] is understandable to reviewers)

Hi, I'm not sure if your way of writing try and catch is correct, I checked the Java coding standard, and I think perhaps the style should be:

try {

 do something;

} catch (some exception) {

 do something;

}

Maybe the try and catch should have the same indention as the line "String command = sc.nextLine()"? Currently I think there might be four more spaces in front of the lines.

Maybe can put the conditions into a separate function? I think it might be a bit easier to read.

Maybe can try to save the line string as a constant named something such as "LINE"? Then it can be called whenever you want to draw a line

The method might be a bit too long and complicated, and it might get more complicated in the future development. So, maybe can try to separate out some smaller methods from this long method, or separate some functions from this method to other classes?

The function seems be a function reporting new tasks being added, so maybe it is a bit better to make the name of this function more specific? PrintTask might be a bit general. How about naming it as reportNewTask or reportAddTask?

Maybe it is a bit better to make the constructor of Task protected? Since as the super class of Event, Todo and Deadline, it should not be allowed to be instantiated directly.

Maybe it is better to name the function as getTaskCompletion according to coding standard?

The processInput function seems to be a bit too long, and if there are more commands added in the future, it might get even longer. Is it better to have a new class to share some work of this function? Maybe a CommandSet class.

I like the way you parse String to LocalDateTime.

I like this exception message.

Is it better to have an exception class called something such as "InvalidIndexException" which extends ChatterboxException?

Is it better to put this message into Ui?

Is it better to use assertThrows function here?

Perhaps a break-down of just the classes that you need, instead of importing all?

This is very minor, but I think you can add a full stop at the end of the line.

For 2103, I think it is recommended to not use indentation for case clauses.

Just a personal preference; I think creating a new Main class to run Duke can be an option to consider.

Same as above, I think it would be better to import the specific classes that you need.

Same as above regarding adding a full stop.

Same as above regarding the usage of indentation for cases in a switch statement.

Very minor again, but maybe can delete the empty line.

Although the method's function is obvious, it might still be good to add a JavaDoc comment as the method is public.

This is a minor suggestion based on personal preference. Maybe use 'print' instead of 'show'?

Perhaps add 'get' to the method name, i.e. getTotalNumberofTasks()?

This is just a personal preference too; maybe can add 'AtIndex' to the method name i.e. getTaskAtIndex.

Same as above regarding the addition of 'AtIndex'

Same as above regarding the addition of 'get' word to the method name i.e. getHasDoneStatus() or rather getIsDone()

Perhaps an empty line between description and parameter section of javadoc?

Perhaps an empty line between description and parameter section of javadoc? I noticed the same issue in several other places too.

Should there be spacing after "Exception" and before the curly brace?

Perhaps it might be good to separate logical units in a block of code with blank lines?

I think it might be good to separate logical units in a block of code with blank lines. I noticed the same issue in several other places too.

I like how you break before an operator and after a comma, I have also noticed this in other sections of your code! 👍

I think you might have misspelled something here?

Is a @param tag here necessary?

Perhaps a more descriptive name such as deadlineDate might make its use clearer?

Perhaps it might be good to include a blank line between description and params of javadoc?

Perhaps a more descriptive name like eventTime might make things less ambiguous?

I like how you name the booleans so that they sound like booleans! 👍

Is invalidInput a verb?

Perhaps it might be better to abstract out the different types of command methods into different command classes inheriting from a main Command class?

toDisk gives the impression that this method is writing the task to the disk. Maybe toDiskFormat would be a better way to put it?

Not sure what these comments are doing here.

This line of code is reused many times within this class. Maybe you might want to put it into it's own function to reuse, like sendLine() or something similar?

I see this "No newline at end of file" in many of the files here. I don't believe this was specified in the coding style guide, but maybe GitHub is complaining about it?

Sections like these are quite deeply nested, maybe you might want to refactor this? The other methods in this class also have this issue. See the textbook page for the section on deep nesting.

The name of this method isn't unclear about what it's doing, but it doesn't quite fit the format of being a verb. Maybe markAsDone would be better? list could also be renamed to showList, and add could be more specific with what's being added to where.

Perhaps this method could be named better? Maybe getGreeting() might be better, or simply save this as a constant String GREETING instead of putting it in a method. Interesting logo though.

Adding a line break between the package and import statements would help to improve readability.

A line break could help to make this more readable. See "Place line break to improve readability" in the style guide. Some of the other else if statements in this method could also do with a line break.

On another note, this entire method is quite lengthy with many different cases, and it may be a good idea to try and break it up in future iterations.

Seconded. addTaskToStorageFromString might also be a possible option.

Minor nit with the method name here, but perhaps saveToFile would be more specific as to what this method actually does?

Both Deadline.java and this file have missing Javadoc comments for only this method within the class. The method name can be a bit vague about what it's actually converting the date/time to, so a quick return clarification in the documentation would help a lot.

The naming for the test methods can be clearer. For example, doneCommand_exceptionThrown tests for an input that does not give a proper numerical input, so doneCommand_noNumberGiven_exceptionThrown could be a better name under the featureUnderTest_testScenario_expectedBehavior() format outlined in the coding standard. Although the standard does allow for the omission of the 2nd and 3rd parts, these tests may not be exhaustive enough to justify dropping the test case section of the name, especially if other exceptions may arise from entering the command in different ways. The other test classes also have a similar problem with method naming.

The featureUnderTest_testScenario_expectedBehavior() format should, at least, include the 1st section of the feature under test. Perhaps dateCommandExecution_dateDoesNotExist_exceptionThrown might be a better way to name this?

It is better for "duke" to be PascalCase.

Documentation format is a bit off.

Can add javadoc for this method.

Can add javadoc to this class

Can be more specific instead of using "*".

It might be better and cleaner to put "tasks.txt" in a "data" directory

Can seperate the TaskList from Storage class. Storage class might not need to know the TaskList class.

Same as above. Can seperate the TaskList from Storage class. Storage class might not need to know the TaskList class.

This method can be in Parser class instead.

Can this field be private?

Perhaps a missing full stop here?

I think there is an empty line between description and parameters :"( for other javadoc comments also!

I think its a bit strange to have a load method inside a Task class? Maybe you can consider having a SaveAndLoadManager to handle all the saving and loading of tasks? Just a suggestion hehe

I'm a bit confused here... maybe can change the variable "input" to "detail" like in the parse method because for some reason i assumed the input is the whole string ><

I think maybe can factor our the arr[0].trim() a bit earlier here?

I like this part!!!! So neat! Can I learn from you? 😊

Maybe this part can be abstracted into another method? like 1 method to read the file and another to convert the read data to actual objects.

This is so clever! I used for loop guess now I have to change 👍

This part maybe can consider abstracting it into another method (convertListToString or something) because it can be reused (in list() for example) I think?

Command pattern! Nice!

Should there be an empty line between 98 and 99?

and other javadoc with description and params too 👍

perhaps this space here can let go?

also maybe the description should start with Returns instead of Return?

I notice that you missed out the return parameter. Will it be better if the Javadoc comment for this method specify exactly what will the method return?

I like how you used System.exit(0) to properly exit the bot. 👍

In this Javadocs comment, it seems to not be followed by Command class immediately. Perhaps you wish to shift it below the import line? 🤔

There seems to be a missing space between Command and { here. I notice this issue in a few other places too, you may want to relook at it again?

I like how you allow users to find tasks using date as a keyword as well, instead of just task name. 👍

I like how the handling of exceptions are handled by various duke exception classes 👍

Will it be clearer to user what the method does if the method name is changed to "hasSpecificKeyword"? 🤔

Will it be clearer if the file is stated, e.g. toStringDataFile, instead of just file since it may not be clear to user? 🤔

I like the clear naming of boolean variable here. 👍

I like the use of enum here, resulting in neat code when parsing user's input.

Appropriate use of streams in this class, resulting in neat code. 👍

Will it be better if the javadocs comment here include the return parameter to specify what is the String that is returned? 🤔

Will it be clearer if the javadocs include when this second constructor could potentially be used to create tasks?

Perhaps by is not the best option to name this variable?

the naming of the variable "msg" is probably questionable

A lot of duplicate code because the "isExit" method is overridden for quite a number of that. I suggest to adopt another approach towards handling the exit of the program:)

As for me, I find the multiple "if"s not as readable as "if-else if" blocks, but even if the logic permits, it is still totally up to you whether to change it or not.

perhaps you could consider changing the naming (a couple of other similar issues as well).

yah I agree with the former reviewer that the error could contain an error message

yup this should be an extra line break

I think according to the coding standard, the description should start with "parses" instead of "parse", this should apply to all your Javadocs.

I'm not sure whether the layout here is correct... consider adding a blank between "]" and "{", consider changing the indentation to 4 characters instead of 8.

yup the line break could be removed

Javadoc for this method (optional)

extra blank line, a couple of other similar careless mistakes as well, will stop mentioning from here onwards.

Agree with the previous reviewer

"this." keyword not needed, since there is no conflict in name.

A bit long. Might want to break it.

Consider breaking the strings so that it represents more closely to the string that will be outputted. Might want to consider as well using String.format() for this.

Might want to rename to hasExited instead.

Might want to use something "rarer" for separator, to avoid error parsing tasks with "|" inside.

Test looks very detailed. Nicely done!

Should leave empty line between descriptions and parameters. Same for the rest of JavaDoc comments.

A bit dangerous to use the symbols directly in source code. Consider using their Unicode equivalent instead. Same comment for the rest of the usage of symbols.

Not too sure what this comment is about.

No need for "this.", since the scope is clear.

Method name and description not obvious on what this method does(String is returned as side effect)

Might want to make Command class abstract if you have abstract method.

Might want to indent properly to give a rough idea of what the string looks like. Or even use String.format to avoid repeated usage of + operator.

Might want to reconsider the naming of testing methods (refer to coding standard).

Maybe set private and final for variables? Since you're not modifying it anymore

Try to avoid while (true) ? I think its generally bad practice? Can replace with boolean flags

remove readability, do you mean improve readability, kendrew chan?

+1! Beautiful code!!

Amazing use of enums

+1, overall very clean and well-designed code

I like how you edited the README to showcase the current state of Duke chatbot

Wow! I really like how you're taking the step further to add different dialogboxes

Maybe the type can be of the enum that you created, instead of string?

Maybe create a separate class to handle returning String UI? Like a UI class they suggested might help your code look cleaner

Maybe can extend ArrayList instead of just holding an arraylist?

Its better to make the constructor private just in case you create a random enum not found in your list of actiontypes

Very organised, nice

I like how you have defined the error messages in a single place: it makes it much easier to change!

I think you can consider shortening this method (as it seems quite long) by creating other private methods as helper functions! 👍

Perhaps you can use a more descriptive variable name 😃 I notice this in other places too in this method

You can consider listing explicitly the classes that you are importing!

Maybe you can name this as "printBye"? I think it will be more consistent with the rest of the method names, and it also sounds slightly more like an action 😃

I think you can consider explicitly listing all the classes you are importing! 😃

Perhaps getMenu would be a better method name as methods should be named using verbs.

Maybe the header comments for a method could start with a verb instead of a noun? In the coding standard, they have some suggestions like "Returns", "Sends" etc

I like how you have structured your application! I think the classes are really well organized in their packages!

I am just being nit-picky here but you can consider changing it to "Prints" instead of "Print" as described in the coding standard. I noticed this in several other places too

I like how you are using abstraction here!

Maybe this method can be called "convertDateToLocalDate" to sound more like an action! 😃 Noticed this in other places too!

You can consider removing the indentation for the case clauses. I did the same thing too in my codebase previously but it seems like the coding standard is saying that there is no indentation haha 😃

i think according to the Java coding standard, the first sentence of the method header comments should start in the form of "Returns ...", "Adds ...", etc. so maybe a better way to describe this method could be something as simple as "Drives the program."? i think this applies to some of your other methods in your other classes as well, especially your constructor and class descriptions! 😬

i think generally u have to explain what is the parameter used. i know you did not include an explanation because it is unused. im not sure exactly how it works but maybe u could put something like "@param args unused."? 😺

to improve your code quality, maybe you shouldn't use magic numbers 😜 you can instead create named constants for each of them! e.g. private static final int TODO_COMMAND_NUMBER = 1;

i realised that for some of your methods you initialised your taskNumber as -1 first. im not quite sure why you did that and there might be a reason so please ignore this comment if there is a reason. but i feel like the initialisation might be redundant? you could probably just shrink this method down to:

public int ........... {

return markDoneTask();

}

just a suggestion!

perhaps these one-liner methods might be a little redundant? i understand your POV but since these commands do not need to be 'parsed', maybe the commands can just be returned inside the switch statement? just a suggestion! 😅

i don't think you need to add a newline in between cases? or perhaps this might be unintentional? 😂

perhaps the method name could be changed to 'saveTasks' to make it more meaningful? i think just 'save' might be a little vague, don't you think? 😕

maybe the parameter name can be changed to 'index'? i don't think it matters much and i don't think it violates the coding standard in any way since the 'i' is only used temporarily, but in my opinion it might improve readability 😸

similar to the 'save' method i mentioned earlier, maybe this method could be named 'getNumOfTasks' or 'getListSize' or something along those lines to make it more meaningful? 😬

just FYI, if you generate the javadoc with this return section, the result will show something like this:

Returns:

Returns the removed task.

so if you want to, you can remove the "Returns" just to make it a little nicer (this applies to all your javadoc comments, not just this one), not important but just a small suggestion if you didn't know! 😁

perhaps this method name could be 'findRelatedTasks' to make it more meaningful, similar to my earlier comments 😄

perhaps this could be 'printList' instead?

perhaps you could have a little explanation why this command returns a false?

This method feels very long. Maybe you can consider refactoring this.

A suggestion would be to create a Parser class to process the input, and a Commands class to contain the logic for each individual command.

Your try-catch blocks all look very similar. Perhaps you can factor this out into a function (and put it in the Command class mentioned above).

The Main class seems to be doing too many things. I would suggest putting all these createXXXX functions in another class.

Since you are using many different exception classes, I would suggest putting a default msg string instead of always taking it from the constructor.

So instead of doing

throw new DeleteIndexOutofboundsException("\n\tYou have typed in an invalid number.\n\tPlease check your list again.");

in your code you can simply do this:

throw new DeleteIndexOutofboundsException();

Also makes those sections easier to read.

Not too sure but IIRC it's safer to inherit from Exception rather than RuntimeException?

In case you forget to catch a LukeException the compiler can warn you then.

Do remember to add proper tests before the iP deadline!

Maybe you committed this accidentally, but if this is intentional you may want to add a comment as to why this class is blank.

I noticed that you commented out several lines of code (also on lines 15, 50, 51, 57 and 58), perhaps you could write another preceding comment to explain why you commented them out?

If these changes are 'experimental' or 'exploratory', you can try using the git stash command to store them locally instead.

There's only 1 list in this function so maybe you should name it just list or taskList since there's no ambiguity. (A confused reader may try to look for a list2 otherwise).

I've also noticed that in your code you named your TaskList instances as list. I think this is fine for now, but you could consider using a clearer name like taskList so there's no confusion with instances of java's util.List.

Same for line 55.

The logo and line variable names should be in UPPER_SNAKE_CASE to conform with the style guide, since they are being used as constants. (I think you may also want to make them static, since they are shared among all instances of this object).

You should add JavaDocs here, since this is a public class.

Same as DeadlineStub.java, you may want to add JavaDocs.

Instead of putting several tests in one function, maybe you should split them up into several functions so it's easier to see which individual test breaks the code (now if this addTaskTest fails you will have to comb through all the mini tests here to see what went wrong).

Also I think it will be clearer if you added a short comment to describe what you are testing for in each test.

There are some recurring inconsistencies with usage of white space. It might be good to review to keep it consistent with the rest of the code base.

for example: if (exist) would better adhere to coding styles than if(exist)

Names representing methods must be verbs and written in camelCase. For example, getName(), computeTotalWidth()

So, if the intention is for you to get the value of first slash tracker, the method name could be getFirstSlashTracker instead

It seems like you are making a line break in order to follow the rule of line length not exceeding 120 and that is great!

However, line breaks should be done before an operator. One possible way could be to change this line to the following format :

System.out.println(" Yup, this is now added! " + " [E][x] "

order.substring(5, number) + "(at: "
order.substring(number + 3) + ")");

the operator should be a part of the new line when wrapping lines. Hope this example clarifies 👍

I quite like the clarity in your comments, some quick tips for readability and adherence to javadocs standards - JavaDocs general comment section should have one line break from the remainder.

For instance, it should look like this:

Return the symbol of the status of this task.
@return ✓ if task is done, ✘ if task is not done

I like how you are adhering to encapsulation principle by making your attributes private. I had some trouble deciphering what does the at variable represent without reading the rest of the code base though. Would it be better to refactor it into "atDateTime"?

*this could apply similarly to the code for the class deadline as well 😃

Would it be better to turn this into "loadFile"? (Just to aid in readability!)

Would be a good idea to consider refactoring this into a separate class to handle the UI of JavaFx instead of having it all in the Duke class. If we try adhere to the SRP, it would probably be best for Duke to handle the underlying implementation logic of interacting with commands? Then the separate class could handle the UI?

It seems like you are doing these generic checks rather often. In order to promote reusability of code, would it be better to refactor the checking into a separate method, and call that method in one line as needed? (Inside of the execute method probably)

Names representing methods must be verbs and written in camelCase. e.g. getName(), computeTotalWidth()

Suggestion here would be to change it to getSimplifiedTaskString()

This minor infraction is similar across all objects extending from Task, so they could be refactored similarly

Not a requirement for test code, but it is recommended to write in tests in the following format -> whatIsBeingTested_descriptionOfTestInputs_expectedOutcome

Rationale is that when you see errors occurring due to your unit tests, it would be good to be able to trace exact test case scenarios and narrow down the scope of why errors are occurring. It would be particularly important in the case of regression testing. Once code bases grow larger, it would be easier for other developers who are working on the code together to realise what problems are being created when they refactor the code without prior knowledge in an effort to introduce new features.

This is really more of a personal preference than actual error. I would think that the commands being added are rather literal in their meaning, given that they are actual words and not magic numbers or characters.

Would it not be sufficient to use the strings themselves in the switch case statements?

I liked the use of static final here to give these strings a named constant for readability!

I realised that you chose to save the file to storage after execution of each command. I was wondering if that was indeed necessary, given that file I/O operations are in general more expensive and might slow down the functionalities. Instead, you could try using storage to write out the file after multiple commands are executed only at the end of duke's life cycle when the bye command is issued?

This is understandably more of a design decision though.

Good use of comments! 👍

Would it be a better practice to make these fields private? Could it be placed before the methods?

Would adding extra line breaks improve readability?

I really like that there are description on specific lines of the gradle to explain the use of that particular line

I feel that the readability of the fields are alright in this class. However, I do agree with @dianneloh9 that line breaks can inserted between different methods.

Could inserting line breaks between these arguments improve readability?

Will it be better to store this string message as a constant?

Would leaving a description for this method allow others to better understand what this method does?

This is a good description that explains the use of the class 👍

Nice explanation of the method here!

Great use of enums

May consider adding some description to the parameters

Good use of line breaks

Maybe you can change "by" variable name to be more descriptive? Can consider "timeDescription"?

Similar to Deadline class, could the "at" variable name be changed to something more descriptive?

Should underscore be used for naming here? According to the coding standards, underscores may be used in test method names and for constant names that are all caps (eg, MAX_ITERATIONS).

Consider storing "O" and "X" as constants and then referring to them?

I feel that it would be better to add 1 empty line at the end of this file so that git knows that the file terminates here.

Can consider changing "greetings" method name to a verb form such as "greet".

Just a personal opinion, I feel that modEcho name can be more descriptive?

I feel that the processTime name can be better? Maybe it can be called as processTimePrefix?

Could modNext be named better?

Saves* the data from the updated task list...

Maybe you can consider making "Y" and "N" as private final variables and then refer to them?

Should add in @return too?

Maybe you could change sayBye name to showEndMessage? To be more in line with showStartMessage.

I think you're missing a header comment for this class and some other classes?

I don't think there's a need for indentation for case clauses? likewise for your other case clauses in other classes

I think you're supposed to package your classes?

I like how neat your main class is! 👍

I think you're missing the return type of the method in the docs and in some of your other methods too?

I think you're missing the parameters of the constructor in your docs?

I think your @param has to be on different lines like your other methods?

I think you have to specify the return type of the method in your docs?

I think you have to leave a line between the description and the @params section?

Ah I see. Thank you for the clarification!

Do you need to document this method?

I like how the names of your methods are very clear and readers know exactly what each method does! 👍

Perhaps you might want to consider combining the if-else statement with the try and catch and catch the NullPointerEception.

As per se in java coding standard (there is no indentation for case clauses) hence you might want to consider removing the indentation.

You might want to consider adding JavaDoc to Constructor.

You might want to consider adding JavaDoc to Class.

wildcard import is not encouraged according to Java coding standard. It would be better to list them out explicitly.

You could consider changing parse to parseInput instead. So it is clearer that this method is used to parse the user input.

Perhaps you could consider changing this method into a shorter method by extracting out some of the operations and make a new method. This could help to improve the readability of the code.

Perhaps you could consider putting a space between line 3 and 4 which follow the other classes' import's grouping?

Consider changing Mark to Marks to follow Java coding Standard.

It looks like you miss out a full stop behind the tasks.

Perhaps you might want to consider putting Cap for the first letter of the description. For example: The user input

It looks like you accidentally miss out the description for context.

Oooo ok. thanks for the explanation:)

According to the module's coding standard, should the + after "(by: " be on the second line instead of the first line?

According to the module's coding standard, should the + after "(at: " be on the second line instead of the first line?

According to the module's coding standards, should the javadoc header comment start in the form of Handles ...?

According to the module's coding standards, should the method name showIOException be showIoException?

According to the module's coding standards, should import static org.junit.jupiter.api.Assertions.assertEquals; be put above import org.junit.jupiter.api.Test;? The same comment for all other classes that have those two imports.

According to the module's coding standards, should a javadoc comment exist above the method? The same comment for all other public methods.

According to the module's coding standard, should there be an empty line between the header comment and the first @param? The same suggestion for all other javadocs comments.

According to the module's coding standards, should a Javadoc comment exist above the public class Command? The same command for all other classes.

Should the name filepath be filePath?

Should initialiseWriter be named initializeWriter?

Should the method name newStorage start with a verb? I think I prefer initializeNewStorage.

Should import static org.junit.jupiter.api.Assertions.assertEquals; be above import org.junit.jupiter.api.Test;?

Perhaps you could change the variable's name to isBye instead of bye since it is a boolean?

Perhaps you could include a "break;" after this line? I think this you missed this as you include break for every other cases.

Maybe you could add a space after "name," so that it follow the java coding standards?

E.g: super(name, isCompleted)

Maybe you could add space after try to follow coding standards?

Same as try, maybe you could add space here after catch?

Perhaps you could add space like this (DukeException e)(spacehere){ ?

Perhaps you could add a default case?

Perhaps you could add a default case here?

Sometimes you have "space" before the "{", sometimes you don't. Maybe you could have a fixed standard? I recommend having "space" before "{".

Perhaps you can use the contains function of java String?

Maybe you could reduce the length of this method, as it exceeds 30 LOC? Maybe consider adding method registerTasks. registerCommands, etc.

I think this line is a bit too long as it exceeds 80 characters. Perhaps you could make it into 2 lines?

Maybe you could try avoid "magic" number/string like "Send", 600.0, 400.0? Maybe can consider adding named constants for them?

Consider putting an empty line between the description and parameter section

Missing space after Command

Maybe it would sound better if it starts with "Displays"

Try to avoid using .* import

Extra space after parse

Missing Javadoc for getStatusIcon() and changeIsDone()

Do add an Assertions.fail() for cases testing on faulty inputs.

Reason being test cases will be marked as pass even if there is no exception caught.

Change the test method name into three part format.

testExecute_wrongFormat_ExceptionThrown()

//for subsequent test method name as well.

I like how you have separated the DukeException into smaller exceptions. Made reading easier!

Consider adding an empty line between description and parameters section

Can consider using {@inheritDoc} tag to indicate Javadocs inherited from parent class.

Reason => May not know if unintentionally left out, or supposed to be inherited.

Prevent alerts from checkstyle also 👍

Might want to add a single line Javadoc comment for class members / attributes.

Perhaps can consider using a switch block here?

Perhaps OOP could better represent this block of logic? Like having a Command parent class and extending it with multiple logic classes such as AddCommand which extracts the logic out

Maybe a more concise way to do this is for DukeException to extends Exception so you could simply pass the ErrorMessage to the constructor (and super's constructor)

Perhaps making this an ENUM would be more appropriate?

I like how you've extracted the logic behind reading and writing to a Storage class! Great job! 😄

Perhaps this could become an abstract class since we're not dealing with Task directly (and we wouldn't want the user to accidentally make a Task object either)

Classes that extends Tasks could be packaged into a subpackage eg: main.java.task for a cleaner look 😄

Perhaps a more apt return type would be boolean? isDone ? true : false

Maybe it's better to park file_dir and file_name under Storage since it's responsible for reading/writing? 😄

Perhaps returning an enum instead of a "T" would be easier for co-dev to understand this function!

Perhaps split the logic in ui.processRequests() into it's subclasses so it'll adhere more to SOLID principles? Especially Single Responsibility Principle!

Perhaps calling it something else other than echo would be more apt? Echo suggests that Duke only echos! Whilst in the method you're doing alot more than just echoing 😃

Perhaps using the UTF representation of a tick is better than a "O"? Since the variable name is TICK

Perhaps the HORIZONTAL_LINE under duke.java can be removed since this is here? 😄

Don't forget to put punctuation behind each parameter description!

Should we put punctuation behind each parameter description? It might also be nice to start the parameter description with Capital letter:)

How about using a name that has plural form? Would that be better since this is representing a collection of objects?

Perhaps the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)

Remember to add a javadoc comment here!

Remember to put empty line between description and parameter section! Also, perhaps some periods should be added.

Nice that yout variable is named to sound like a boolean!

Nice to have the correct indentation for swtich cases!

Don't forget to always put a new line at end of file. Git likes to complain about that.

It took me a while to figure out what des is. Perhaps it will be nice to change the name des to a more meaningful name. 👍

I really like how you keep this shouldExit() as a method and override it in child class!

Nice to have not just DukeException but the specific exceptions!

Nice to follow the coding standard and put javadoc comments in this week's files as well!

According to the coding style, case labels inside switch statements should not be indented further.

Small issue, missing a space after the , here.

(there's other instances of this from the same code in the other classes)

I'm not too sure about this, but should the statement on line 20 be indented 8 extra spaces here?

(really not sure, the style guide is super vague)

minor nitpick, but the /** should be on its own line here right?

The javadoc description should be on its own line here right?

(ps: i'm not gonna make any more style comments! just not sure how many comments to make >< )

Would this be better phrased as getTaskDeadline()?

The base class java::lang::Exception already has a constructor taking a message, so i think it would be less repetitive to use that, so you can do super(message) instead?

This method is a little sketchy IMO, so here's some friendly suggestions!

it should make the code cleaner if you used string.split() or a Scanner to iterate through the tokens, instead of manually checking the length of the input string and doing a manual match

also, i don't think i've reached the part where you call this function yet (i'm just scrolling from the top), but it's kinda weird (imo ofc) for a method to return an exception instead of just throwing it? for this kind of paradigm i think it might be better to use Optional in conjunction with an error message, or just make the method throw?

it might make sense here to factor out replyArr[0].trim() to a separate variable, so it's less repetitive?

also, you might want to use string.strip() instead of trim(), since the former is unicode compliant (:

also, regex might be a good idea here as well?

this is a pretty big code smell! in conjunction with line 116 in NewIoHandler, there's definitely a better way to handle this; as mentioned for the other method in this file, you could look at optionals, or just making the method throw the exception.

this might be a problem since you initialise it statically; if the user deletes the folder for whatever reason in between saves, it might exist at first but disappear later

could these be made final?

Maybe listing all the imported classes explicitly would be better!

I really like the extensive use of final variables here as it is easier to amend code in the future. There is also less likelihood of typing errors.

Maybe we should change the method name to addDdlTask instead to adhere to the Coding Standard

Perhaps it would be clearer if we changed the class name to something like TaskWithTiming so that it is more easily understandable

I like how you did the enumerations, similar to declaring static final variables, it makes it easier to amend code in the future and there is a smaller chance of careless errors this way

Any reasons why you decided to use an empty catch block instead of handling a possible IOException?

I like this way of distinguishing an exit command. Perhaps the Javadoc comment could elaborate more, by saying that all commands return true except the exit command.

I like that you did the enumerations as it reduces the likelihood of careless mistakes in code!

Maybe this line can be removed

I like that you give descriptive errors that improves user experience!

Maybe inserting a space after the "if" would help adhere to the module coding standard

Maybe it would be clearer if you renamed this method to evaluateDoneOrDelete, as the user input is "done" and not "complete"

I like that you used OOP concepts when writing your exception classes, instead of lumping them all into one DukeException class [which is what I did D:]

Perhaps a more intuitive variable name could be used instead of COMMANDS? I was confused as I thought COMMANDS also included add, bye, list etc.

Perhaps a clearer name could be used? It could be confusing as the method name does not refer to any object noun that exists. Eg. doesSaveFileExists

Are you missing a javadoc description for this method?

I think it will be better if you could split the unit tests into individual test classes for each class you have.

I like that how you abstracted out the commands into a Command class, and made it an abstract class.

Perhaps this String variable is not necessary as you already have a boolean to represent whether the task is completed.

Perhaps a more intuitive variable name could be used, eg. taskDescription? It will match your javadoc comment too.

I got confused here, why do you return an empty string if this method is convert the task to a string form that is to be saved?

Update: I see you that you've overridden this method in the child classes. I suggests turning the Task class into an abstract class since a Task is not instantiated, while its child classes are.

Wow! I think this is a really nifty customization that you have added to the iP.

Perhaps you could've renamed the Duke class to Focus class since you're bot is named Focus Pocus? It is a cute name, by the way.

I realised that you only have one DukeException class that covers all types of Exception that could be thrown. I feel that these Exceptions could be abstracted out, eg. InappropriateDescriptionException, InappropriateCommandException etc, to be more OOP.

Perhaps this should be an Exception as the Command class should represent the commands that the user can input?

I think you had a typo here. It should be is an ExitCommand.

Should there be a separation for this import statement from the rest?

If i am not wrong, there should be a separation here as well

Method might be too lengthy

Perhaps getTask(int i) might be more specific

Perhaps getSize() might be more specific

Perhaps UIPrint can be replaced with UiPrint here

Path/File names might sound like boolean variables here

I like the specificity of the error message shown

I suggest having a DukeExceptions class and storing the 'OOPS!!!' message in the class (Makes the message specific to all DukeExceptions)

I like how you created another class for time formatting 👍🏻

Use of stubs 👍🏻

Great that there is a method for this

I believe case clauses should not be indented

I think egyptian style braces should be used here

I'm not sure about this but should the variable names be dateTimeArray and dateTimeString instead?

Perhaps you can consider placing 2 comments here to be clear that fallthrough is intentional here?

Here the Javadocs opening /** should be on a separate line and there should be a blank line between the description and parameter section

small typo (should be @param instead), and every parameter description should end with a period

Theres an extra whitespace at the function name

I think egyptian brackets should be used here

I noticed that DeadlineException and EventException extends TaskException but the rest extend Exception. Would it be better if all your relevant custom exceptions extend a custom parent exception (e.g. DukeException) so that you can change this method to "throws DukeException" instead?

Hmm maybe you can consider naming your test methods with the following format featureUnderTest_testScenario_expectedBehavior()

Is this method necessary since it is just calling the overriden toString() method in line 65?

Ah okay I understand what you're trying to accomplish! In that case maybe you could consider making Task an abstract class (if your current code allows for it), so that you may declare stringify to be an abstract method so you wouldn't need to give an implementation for it in Task (this is just a suggestion though, feel free to ignore this!). I do agree that your suggested method name is much clearer 👍🏽 Thanks for the clarification

I meant that for test method names it may be better to describe the test within your method name. One example given is intDivision_zeroDivisor_exceptionThrown, which describes to readers that the test is testing for integer division using zero as a divisor, and the expected result is an exception being thrown.

In this case maybe you can consider naming it isExitTest_byeCommand_returnsTrue? Again this is just a suggestion though, apparently the coding standard guide states that the "Third part or both second and third parts can be omitted depending on what's covered in the test."

Note the spelling error for "wites" -> "writes"

For methods that return void, there is no need for the @return tag.

For methods that have parameter(s), you have to include @parameter tag.

Perhaps a description of what the arraylist is about can be better?

I think there should be only one white space between "String" and "getContent()". Perhaps using the checkstyle file will help detect such errors?

Should these 2 attribute contain this. too?

I think there's a wording error here ("the" -> "that").

Note the camel case format for methods.

I like the use of StringBuilder to reduce concat time.

Perhaps you could use isBye to be more consistent with your other methods?

You can be more explicit for parameter names so its easier for the code reviewers 👍

I like the use of ellipsis to simulate loading duration.

It is 4 spaces for next line if you break the @param description.

Maybe add whitespace after the Exception before the {

There should be an empty line between the Javadocs method description and the params.

Maybe abstract away all the split and other string-processing operations into the Parser class. That would make the Tasklist class much simpler and readable.

Final constant names should be capitalised, eg. HELLO_MESSAGE, BYE_MESSAGE, ERROR_HEADER.

It would be better if this comment was split into two lines.

I like how you declared final constants for the delimiters. I will learn from this for my own code.

Might not be necessary to add a blank line to separate the parameters, return values and exceptions.

Maybe it would be better if this comment was phrased according to the Javadocs standards, eg.

'''

/** Indicates the type of task */

private final String commandTag;

'''

It would be better if you would indicate in the Javadocs the circumstances in which the DukeException would be thrown.

I like how you created an enum class for the error messages. It would make all the errors more organised.

Not sure if the explanation for parsedInput is clear enough.

Good that you declared the TICK and CROSS as final variables.

It would be better if you give a brief description about the parameter of the function.

I like how you put spaces between the lines, it makes the code look cleaner and more readable.

Perhaps it would be better if you store all these messages into 1 variable, and you can just System.out.println that single variable.

LGTM

Perhaps it would be better to name the conditions in the bracket as isEndDateNull.

Perhaps it would be better to give these three variables brief descriptions.

LGTM

Nice way to help the user to get to know the commands.

Since the System.out.println(" _________________") is often used, perhaps it would be better to make a function to print that line, and you can just recall that function as many times as you want.

Perhaps it would be better to store the keyword of every command in some variable, e.g. COMMAND_LIST or COMMAND_BYE , etc.

Perhaps it would be better if you store the "todo", "deadline" and "event" in separated variables, for an example String ADD_TODO = "todo" to improve readability.

I like the way you separate lines, it makes the overall code more readable.

Should the method start with lowercase "g"?

Perhaps you might not have completed the @return statement?

As plural form should be used on names representing a collection of objects, perhaps you could change the name of the variable?

Perhaps you might want to change the "removes" to "Removes" to standardize the comment format with the rest?

Perhaps you might want to add a comment here describing the method since descriptive header comments for all public class / methods are to be written?

Perhaps another method can be created to contain " | " + (task.getDone() ? 1 : 0) + " | " + task.getDescription() + "| " to make the code more readable?

I think perhaps you could abstract "/ip/src/main/java/Data/TestFile.txt" to avoid magic strings?

Perhaps the naming of this method can be changed? The usual convention is whatIsBeingTested_descriptionOfTestInputs_expectedOutcome.

I think perhaps a space could be added in between these 2 sentences?

Perharps you could break at the + as the statement exceeds 110 characters (soft limit) / 120 characters (hard limit)?

Perhaps a switch case could be used here?

Perhaps the method could abstracted into another method to reduce the length of the method convertToTask?

Perhaps could start the sentence with a verb in the present tense to abide by the coding standard? (eg Checks whether...)

Perhaps could use a more descriptive name - what is stored? Add stored list?

Maybe using the three part format for naming test methods can provide more clarity on what you are testing.

Perhaps could change the verb into present tense, such as markAsDone?

This method seems to be doing too much work, perhaps can consider abstracting the parsing into the Parser class? I noticed this issue in several other places.

Perhaps can consider using the plural form to distinguish between multivalued variables.

Perhaps it would be better to name the class as ItemList?

Would it be better to separate the similar imports into different blocks?

Could consider using isTmpLoadedFromDisk to better reflect a boolean variable?

Slightly unsure what tmp means, perhaps could use a more intuitive name? Maybe temp instead of tmp (assuming it refers to temporary)?

Perhaps could use a plural variable name to suggest a collection of objects? I noticed this in several other places too.

Would it be better to use words instead of numbers to distinguish names? It can perhaps give greater clarity 😃

Can perhaps use a more descriptive variable name, such as file, since it has a rather large scope?

How about renaming thingsToDo to tasks to convey the same meaning?

Would it be better to have a linebreak above this Override statement?

Would it be better to rename timeBy to deadline?

Could toBeAdded be a private final variable?

Could timeAt be a private final variable?

Would renaming toBeAdded to newDeadlineTask be better?

Would print be a better way to convey the behavior of the say method?

Would it be better to remove the additional line-breaks in this section?

Would naming the list variable as tasks better convey the contents of the ArrayList?

done might be a little ambiguous. Would a better name be markAsDone?

Would toReadableTaskFromat be a more accurate description of this method?

I am not sure what this variable is for. Similarly for hour. Would it be better to rename this variable to be more descriptive?

Name should accurately and clearly explain the char, you can consider calling it PENCIL_SYM

Similarly, these emojis could be differentiated, such as ELATED_FACE and RELAXED_FACE

I think this String could be called USER_INPUT, or USER_COMMAND?

It is not recommended to use numbers to distinguish between variables (Under Naming in Code Quality)

This method could be better described, such as calling it markAsDone 😃

Similar to the deadline class, I think the variable name should be changed for clarity

I think it is better to spell description fully, so that it is clearer to others.

I think you can include more details on the params, such as the tasks are referring to the user inputted list?

I think it should be due, not dued 😄

I like how you have separate exceptions for the different kind of errors that could have been thrown by the compiler!

I think you can try using the switch statement which could make the code cleaner, as there would not be as many if else statements?

I think you can also try and implement searching the deadline and event by or at respectively, such as searching for dates?

Have noticed this in a few places, the coding standard advises against the use of this if the reference is clear.

Lol this is very deep nesting, try to refactor it into multiple &&. Refer to: https://nus-cs2103-ay2021s1.github.io/website/se-book-adapted/chapters/codeQuality.html#avoid-deep-nesting.

Maybe a better name can be used for this method and the method below, for e.g. readCliInput vs readGuiInput

Change method name to loadFromStorage for better readability.

Can delete the variable done, delete the if else block and simply use a ternary operator in return, i.e. return ... + (isDone ? "1" : "0") + ...

I noticed you have the same method name in Storage, it would be more readable if the names can tell which class they belong to.

Same as above.

Might be better to change the variable name from d to duke.

Would input be a better word compare to echo?

Could add JavaDocs to public methods like this, not sure why you explicitly suppressed checkstyle here?

Same as above, try to add docs for all public methods.

Probably can remove this one?

Should it be Returns rather than Return? I noticed the same issue in several other places as well.

Should this be split across multiple lines rather than condensed into a single line?

Perhaps this method name can be renamed to something like hasExisting() to more clearly indicate that it returns a boolean?

Should there be a whitespace after //? So something like // Find task ...

Should this empty line be deleted? I don't think it's necessary to have an empty line separating the javadocs and the class

Should this be Adds rather than Add?

Would 9 be better abstracted out as a constant? I see something similar in the other command classes as well

Perhaps instead of making this an abstract method, you could have a default implementation that returns false? That way you minimize code duplication across the different subclasses of Command and you'll only have to override this implementation for subclasses in which you want to return true

Should there be an empty line between the description and parameter section of the javadocs?

Would this class be better named Deadline instead of Deadlines (singular instead of plural) since it only represents a single task? Likewise for Events and ToDos

Would it be better to explicitly check else if (entry.startsWith("[E]")) here instead of just else? Then, in the else block, perhaps it may be better to throw an exception since we don't expect the progam to reach that state.

Would it be better to abstract [T] out into a constant variable within the ToDo class? Likewise for [D]

Class Script is very well documented good job for the extensive documentation.

However Have some concerns regarding the addition of static modifier to many class methods

Good use of an example in the documentation. Thanks for showing this way to make documentation more clear!

Interesting use of Exceptions to cover up for Java System Exceptions thrown.

Boolean Variables should be named to sound like booleans, consider renaming to isExited or some other such boolean sounding name

test cases should be in featureUnderTest_testScenario_expectedBehavior() format even if it is a assertion of a hardcoded enumeration

Similarly snake case and naming scheme as mentioned in usercommand tests.

Also would be good to add a javadoc on what the test is supposed to be about to make it clearer to reviewers what is the expected behaviour for the Unittest

JDoc guidelines suggest we should phrase constructors is like so :

Constructs....

Your code is quite clean in general, but do note that javadocs for all public classes and methods is required.

Perhaps for classes like these that extend off dukeException, we could add additional information about the error itself as compared to having the very generic dukeException error.

This could make the addition of a IllegalValueException have some additional value add.

This datetimeformatter could be made into a static method to reduce magic variables

Nice use of pointers to other parts of the code! I did not know this existed. Thanks for showing this

Why did you use this.tasks instead of tasks?

Is the function body missing?

Should this be removed if not being used?

Great job with the styling of this method, looks clean

Should "ToDo" be written as "Todo" instead like the next method?

Good use of comments and spacing to make this block of code readable

Tests are very neatly structured and readable

Good job crediting the author of the code fragment that you incorporated

Are the brackets required here?

Very minor nitpick but this could be named getSize() instead

Good idea making use of a switch case to simplify your code

Minor nitpick but could have included a comment // Fallthrough like you did in other parts of your code to make it clearer to the reader

In the Duke.java file, line 25, instead of catching Exception in general, you should catch specific Exceptions, so that you can identify the specific error.

It is unnecessary to have a line separator, but this is not a major issue, just that it will make the code look more concise and less lengthy.

You can consider making the String divider into a constant, as it is being called in both constructors. As it is unchanged in each case, it might be a good idea to make it into a constant.

The "+" operator should be in the next line.

There is no need to declare an empty constructor method. When there is no constructor declared, you can just use new duke() and it will automatically create a duke object with no variables.

Why do you catch (Exception)? I think it might be better to catch more specific Exceptions, rather than to catch all Exceptions and its sub-classes.

It might be a better idea to name the variable for LocalDateTime, something more clear, instead of just calling it "by".

For example, "toBeCompletedBy".

You might want to consider using switch and cases to make your code a lot more readable. I also did the same thing as you, using if else, but one suggestion given to me was to use switch cases, which i find it a lot more pleasant to the readers.

It might be better to catch more specific exceptions than the superclass.

There is no need to declare an empty constructor method.

Shouldn't there is an additional 4-space tab here?

Isn't timeDescriptionFormatted renamed to fomattedTimeDescription better?

Is there any more descriptive way to replace the name string (e.g command, input) ?

Has the name end clearly describe the functionality of this variable?

Just my opinion only, I believe renaming lst to tasks helps to describe the variable better

Due to the coding standard, isn't it be index++ (the ++ sign is connected to the variable)?

Content is not a countable noun, is it?

I believe "T", "D" and "E" are kind of magic strings. Is there any way to store them as final variables and then refer to them?

Is there any way to make replacement1 and replacement2 more descriptive?

Is TITLE a final variable?

These lines should be tabbed in, shouldn't they?

I think there should have 1 space between ...Omega manga", and newTodo...

Should this method name be more specific? I think it is very clear what "it" is here.

Should this method name be shortened to "getListSize"?

Should the class name be singular instead of plural? I think there are some other class names that could be singular, too.

Should this variable sound more like a boolean?

Should the class name be PascalCase? So this class name could be "Ui".

Perhaps consider a clearer name for the method's parameter such as "command" or "input"?

Should this import statement list all sub-packages explicitly?

Perhaps consider changing "split1" into another name like "tokens" or "words"?

I think this variable name "split" here and some other places below might could be changed into a more meaningful name, too.

Good work for remembering to break lines before they get too long! But shouldn't the line be broken before the operators? I think you could move the trailing plus signs to the beginning of the next line.

Should the merge conflict be resolved before being pushed into the remote repo?

Should the variable name be changed into a more meaningful one like "time" or "date"?

Instead of is the main class of..., maybe you could write represents the main class of...?

Since this is a public method, maybe this could have a javadoc?

For the switch statement, maybe you could separate it out into another method, or separate out what to do in each case into multiple methods? As this parse() method seems a bit long

Maybe this method can be named something like getIsFinished() to distinguish between the boolean variable isFinished?

Similar with the previous switch statement, maybe you could separate out what to do in these cases into separate methods, such as handleLetterT()? So that it can be neater and shorter

I like the toSave() method, I didn't think of doing this method, good idea!

Should the first letter of the javadoc comments be capital letters?

Good idea to use optional, I didn't consider it for the tasks!

This method seems a bit long, maybe you could separate out what to do in each case into different methods? For exmaple a handleList() method.

Should this code be removed, since it's no longer in use?

Same with the previous switch statement, maybe you could separate out some of the code into separate methods to make this method shorter?

I think your empty has a typo >.<

could consider being more specific such as 'getTask'?

Similarly could also try being more specific here?

Perhaps could use a better variable name rather than 'df'

naming of list could be more specific?

perhaps a more specific name rather than 'details' such as 'deadline' or 'duedate'

if possible can consider spelling out instead of 'ddl'?

could possibly write 'description' rather than 's'?

could consider labelling this as a variable instead?

could consider more specific method name, such as getTask?

Perhaps you could use a more specific name rather than 'string'?

Possibly rename 'd' to 'duke'?

Perhaps a more intuitive variable name rather that 'c'?

Should taskDataDivided[0, 2, 3] be assigned to a variable that is self-descriptive? It would make the code easier to read and understand.

It might be more appropriate to name this variable as taskList instead of returnTaskList since return is a verb and could refer to a function.

It is good to separate the description and parameter using a blank line.

It may be better to use the Egyptian style when writing if-else statement as it becomes easier to read.

May be better to name it searchTaskWithName(String searchString), as it is understandable by just reading it.

maybe package and import statements can be put together instead of separating with blank lines? especially when importing from the same package.

I think it would be better if the import statements are explicitly mentioned, rather than using *, as it becomes much clearer for others to see and understand.

I like how you separate the description and parameter section

Maybe it's better to add the @Override keyword? So that others know that it is overriding an abstract method defined in the superclass.

I like how you have made the method names to be self-explanatory. Good job!

Should exit be renamed to hasExited as its a boolean?

I really like how you put superclasses as abstract classes.

Is this a typo? Tockbot instead of Tickbot

Should final variables be capitalized?

Maybe leave a line in between imports from different packages. java.io, java.time and java.util all count as different packages. Same for lines 18-24.

"Writes" instead of "Write". Use this tense for other JavaDoc comments as well.

To my knowledge, java.time.LocalDate does not encapsulate time specifically, only date. The use of the variable name LocalDate time in this case might be misleading. May I clarify what form of date or time tracking did you intend to implement?

I second the suggestion made by @YangJiyu98

Perhaps capitalize the beginning of JavaDoc comments? This applies to all other JavaDoc comments as well.

Repeated suggestion. I second this as well.

Perhaps group imports based on the packages and leave an empty line between groups?

Not part of the Java coding standard, but perhaps remove commented code that I would presume is unwanted?

I second that

Hi! Really love the implementation of a HELP case

I think we should camelCase our identifiers, so bad_cmd should be badCmd. snake_case is reserved for test method naming!

Really love the comprehensive documentation for your class. Learnt something new from this, good job man 👍

I think it's a good idea to always put access modifiers to your fields, for comprehensiveness-sake.

JDoc guidelines suggest we should phrase is like so :

Constructs....

You might have missed it out for your constructors, but this week's CheckStyle requirement probably means that you already resolved such issues so this might be a moot point I'm making

Really like your use of Enums to consolidate your Errors in one place, did something similar for mine too!

The use of ChronoField is new to me, thanks for showing this alternative way to handle Date/Time 👍

Hi! Just wanted to suggest putting your UI messages in an enums so you can modify them all at one place and the rest of the classes look much neater. Your coding style is so clean already, this should make it even neater 👍

Edit: On hindsight, I realise that this review should be focused on coding standard violations but thought it's still a valid suggestion, so leaving it here

Similar to @josuaaah 's point about final constant naming

Second this suggestion. Also think that the Parser class should be responsible for checking User input and throwing appropriate Exceptions from there, so that the TaskList can be responsible solely for TaskList related actions without being concerned about the validity of the Task.

It's amazing that you added a custom serialization/deserialization helper to write an editable text file. This makes your text file editable as long as the format of the file is followed.

I chose to use default serialization libraries for to save the entire TaskList object inside, and upon a new write onto the TaskList, to overwrite that file. This is so that people don't tamper with the saved data file and also prevents Storage class from handling logic related to the the format of the content in the file. I didn't know how to value to your PR, so just giving a possible alternative here.

Example for the deserialisation/load helper:

Perhaps this could be an Enum

This pattern looks a little strange.

Perhaps a more descriptive name such as byDateTime would be better.

Perhaps using a getter and setter here would be better

Perhaps spelling "errorMessage" out in full may be better

This method is doing a little too much work, perhaps can consider using a switch statement and defer the input parsing logic to separate functions

Nit: prefer not having single-letter variables when possible

I like this help section

Can consider moving some of the logic here to another function.

Perhaps can consider moving this block to a separate function as well (such as createDirectoryIfNotExists)

Perhaps moving this logic to a function such as toSaveString within Task itself can save some code duplication

Maybe can consider adding a comment here to describe what the unicode characters represent

Perhaps it could be better you name your test cases as per the following getSaveFormat_Success?

Maybe if would be clear to specify what format formats? Maybe formatReply?

Have you consider removing an indentation level for your case statements?

Do you think it will be clearer if your load method follows the name of form loadSomething?

Maybe the use of "this" is unnecessary in unambiguous cases?

Would it be better for your workflow if you reordered your import statements?

Maybe it would be easier to differentiate your variables if you constants had the form SOME_CONSTANT?

Perhaps it would be easier to read if you format the braces?

Perhaps you could reorganize the import orders java.time.LocalDate?

Maybe its better to reorder the exception and task imports?

Do you think it would be useful to add a Javadoc for the add method?

This could be an unnecessary new line?

The parseCommand is very clean and neat!

Perhaps command.strip() could be used to remove the empty spaces after "deadline"? Was thinking how the code will work if someone input "deadline "

Your Duke class is very clean and clear! Keep up the good work.

Just a grammar problem here, 'Parses' instead of 'Parse'

Quite confused with the difference between 'Command' and 'Commands' classes here, maybe another name for Commands like CommandTypes will be clearer?

I like how clean your Parser class is. Good job!

Perhaps can let the user know that a File is created? So that the user is informed of what other files the app is adding to their laptop.

If I recall correctly, the code standard suggests not to use 'this' unless there is ambiguity in the word (like in the constructor) so maybe can remove 'this' over here?

To improve the code quality, perhaps a boolean variable can be used to store allTasks.size() && taskIndex >= 0 here.

Maybe can remove the empty lines here?

a JavaDoc could be added here to describe the format that your Time will turn into

I like how you use streams here.

Maybe you can make the boolean method sound more like booleans?

Should there be javadoc comments here?

Perhaps it will be nice to have javadoc comments here since this is a public method?

I noticed the same issue in several other places too

Should there be a full stop?

Maybe the default case should be on the next line?

Perhaps the header comments for the class is at the wrong place?

Maybe the javadoc comment is at the wrong place?

Maybe it will be better to make the path ./data/duke.text a constant?

Maybe you can declare the strings as constants? For example private static final String BYE = "bye", and use case BYE:

Why did you choose to use ui.printHello() instead of printHello() (the method right above) ?

Might be better to add header comments here?

Maybe you can give a better variable name? Such as response or result?

Enum names are to be written in PascalCase

There should be an empty line between description and parameter section. Same for some of the other Javadoc comments.

There should be a punctuation behind each parameter description. Same for some of the other Javadoc comments.

This method is very long, almost 200 lines of code. Should try to create other classes/methods to reduce the length of the method.

case clauses should not be indented.

Enum names are to be written in PascalCase

Oops, sorry I misread the line while I was reviewing it.

Import classes are not listed explicitly

There should be an empty line between description and parameter section. Applies for all the other Javadoc comments.

Method header comments should start in the form Returns ..., Sends ..., Adds ...

Plural form should be used on names representing a collection of objects

More of a code quality issue, but this method is way too long.

Perhaps you can abstract this logic (and other related logic) to another class (eg. Parser)? To build better abstraction.

Perhaps name to something more obvious? Such as wrapMessageWithLines.

Perhaps you can declare them as constants and follow the coding violations. eg. static final String TASK_REMOVED = ...

Perhaps you can abstract this out into another class? eg. Storage.

Perhaps you can simplify from isCompleted to isComplete?

Perhaps change from saveStorage to saveToStorage?

Perhaps you can simplify from isCompleted to isComplete?

Perhaps you can simplify from markAsCompleted to complete or completeTask?

Perhaps you can simplify from isCompleted to isComplete?

Perhaps similar import statements can be grouped together for readability and consistency?

Perhaps a more descriptive name could be used here such as currentTask. It may be difficult to know what curr means after some time!

Perhaps a new line could be added at the end of the file as well. Git tends to complain when a new line is missing!

Perhaps the comment here could be removed since this is a duplicate of the above!

Perhaps this method could be abstracted out into a few smaller methods such that it is easier to read and debug in the future

Perhaps a constant could be defined in the Ui class such that it is easier to print the indentation

According to the coding standard provided, there should be an empty line between description and parameter section

The fully qualified import could be removed here as well since it has already been imported above

For the case clauses, there should not be any indentation as well! It should be on the same level as switch

Should constants be in uppercase instead? E.g. HORIZONTAL_LINE

I noticed that some of the if statements have spaces before the parenthesis while some do not. Perhaps you might want to choose one and standardise!

Good use of abstraction method printNicelyCollection()for the "______" lines as they may not be used and changed to something else in the future, which makes the code more adaptable. Could possibly use String.format() for a slightly cleaner code where you only use System.out.println(String.format("")) once

Unintended additional space

TaskList inherits from ArrayList which makes the entire codebase really clean

Might be cleaner to abstract this out as String isDoneStr = isDone ? '\u2713' : '\u2717'

CheckStyle convention recommends to import one by one

Would be good to place line break to remove readability

Good use of enums and methods to abstract out the logic to parse the String input

Might be cleaner to abstract out the logic into String variables to improve readability

Good abstraction of a Warnings class

Might want to use at String.format() to make it cleaner

Would be good to abstract out the "_____" as an echo function, so that it can be changed easily in the future. Good use of line breaks for readability

Should the boolean expression day < 10 be in parenthesis (as per the coding standards)? I'm not too sure though.

Should the boolean expression month < 10 be in parenthesis (as per the coding standards)? I'm not too sure though.

Should there be a line gap here?

Should this be in camelCase instead? Or maybe declare it as a constant?

Is there a need for this line gap?

Should this be called "TIME_12H" instead?

I think that case clauses should not be indented?

I think that one gap is enough?

I think this method is slightly too long?

I think that deep nesting should be avoided?

Perhaps this is unnecessary? The basic coding standard doesn't require this, but is suggested by the advanced style guide.

Perhaps this newline can be omitted? The style guide suggests a certain form for Javadocs, doesn't seem to have a line break between.

Like previously mentioned, perhaps the this. in this case could be omitted?

Perhaps a active tone can be used, as recommended by the coding guide?

'''suggestion

 * Runs the Duke program.

'''

Perhaps a Javadoc could be added for this, as it is a public method?

'''suggestion

public void disontinue() {

'''

Perhaps 'discontinue' could be used instead?

Perhaps a try with block can be used here, for an auto flush and close?

What's the reason for using an AtomicInteger? Perhaps a traditional for loop would have sufficed here?

Perhaps globstar could be enabled, so that this script doesn't have to change every time a new package is added?

EDIT: I realize this is out of the scope of the review but ya

Globstar is a Bash feature, it does not exist in batch scripts. Sunfire is ancient and really just used for jumping. There might be several nodes with Java 11. Perhaps xgpe1?

Is there a better way to describe the Deadline class in the Javadoc comment? I understand what you are trying to convey but perhaps it would be better to elaborate on it! I personally prefer this representation as its very concise however it might not be intuitive enough for other readers.

I like this way of initialising the variables as its very concise. However, perhaps you could consider using "this" to refer to the instance variables? I feel like it would be a more explicit representation of the initialisation in the constructor.

Perhaps you could use comments to further elaborate on your "else if" statements' condition? I feel like it would definitely be clearer and will increase readability for readers!

I appreciate how clean your code is in the try blocks! But maybe you could include more spacings and comments between different segments of the code so that it is easier to capture the main gist of your code?

I really like how your Parser class separates different functions in a very intuitive manner to readers. However, perhaps you could provide a more detailed naming to the functions? This is so that the functionality of your functions can be more easily inferred by its name.

I really like how you did testing of the lowest complexities as it shows that you place focus on the minute details of your code!

I really like how neatly the imports and packages were organised and I could see that the other files have similar structures too!

Perhaps you could start your Javadoc comments with a more preferred form (e.g "Initializes" instead of "Initialize")? I've noticed there are some other similar comments but most of your comments are cleanly written and I like how concise your descriptions of the functions are!

Perhaps the ordering of the tags could be improved (i.e param -> return -> throws) so that its more intuitive to readers?

I really appreciate how you managed to pick out minute details such as indenting your string so that its much more readable for readers.

Maybe there could be a way to name them such that it is easy to identify that they are constants? For example, "readableFormat" could be named as "READABLE_FORMAT".

I think there should be an empty line between the description and parameter sections. I noticed the same issue in a few other places as well.

I think we should use the word "Interacts" instead of "Interact"? I noticed the same issue in a few other places as well.

I think the indentation level of case should be inline with that of the switch statement?

Perhaps hasFinished would be a better name for this method?

I think there is a missing description for this parameter?

I think it would be good to avoid wildcard imports? I noticed this in a few other places as well.

I like the check for the trimmed version of the input!

I think it would be good to have an empty line between these two methods?

Perhaps an empty line between the description and parameter section would make it easier to read? I noticed this issue in a few other places as well.

I noticed that some of such comments are always lowercase while others such as this are in sentence case. I think it would be a good idea to keep to a particular format?

Perhaps it may be better to put the class level JavaDoc description above the class declaration statement instead of at the top of the file?

Maybe you could define exactly what is being returned and in what format

Clever!

Perhaps, you might want to consider using a switch-case instead of nested if-else loops so that the code would look neater

Perhaps you can also consider bringing this value (ValidInput.getCmdType(command[0]).name()) out of the loop and assigning it as a String. For example,

String s = ValidInput.getCmdType(command[0]).name().

If s.equals("EXIT") {

//do something

}

This could also be another place where you might want to consider using a switch-case loop (=

For example,

switch(currTask[0]) {

case("T") :

do something

}

I don't think you have the type javadocs for every variable in your code. Some times the code is self explanatory. However, please check with your tutor on this particular feedback (=

Good documentation!

Perhaps you can consider using a switch-case block instead of multiple if-else loops. That will make the code more readable

switch(action) {

case("bye"):

do something

}

I think switching line 59 and 60 would make this section more readable (=

I believe these 2 lines can be combined in a more optimal way instead of 2 abrupt points. Resolve this if I am wrong as I am unable to see the character space limit from github (=

E.g.

Represents a Duke storage that deals with loading tasks from the file and | <>
saving tasks in the file.

cases should have the same indention as switch statement

{ } does not follow the convention. Maybe you can add "break();" at the end of lines for each cases.

Maybe you forget the { } on this line?

The if cases should follow the same format even if it is one line

Maybe all the different commands listed individually for clarity?

convertIntoTasks() seems to suggest a method that will return a Task.

Maybe change the name to addLoadedData or something similar?

Maybe we can have a method in Task that will convert the Task status to the desired String format?

Maybe you can list out the specific classes that is needed?

Maybe you can rephrase the method name as isSameDay()?

Isn't it slower to parse the input String inside the hasTime() method compared to parsing it once you receive the user input?

So if you have 10 tasks, you only need to parse once and uses it rather than parsing it inside every tasks.hasTime()

Any reason why you don't choose to omit the shouldExit() method?

[Same for other command classes that return false as well]

From my understanding, if the sub-class behaves exactly as the parent class, we can choose to omit it and the system can compile.

This seems to behave differently that the typical toArray() where an ADT(abstract data type) is converted to Array.

Maybe you can name it as toSaveFormat() ?

This class should be put into a package.

I agree, destination is not long enough to need to shorten to dest.

Should leave a spacing between curly braces and finally.

Missing Javadocs.

A little inconsistent with the this.at and at. Not that there is anything wrong.

Case statements should not have extra indentation. (they should be placed on the same indentation as the switch statement)

Boolean should be made to sound like a boolean. Perhaps doesWriteData?

Should leave a space before the opening curly braces for the method.

Your classes should be packaged for better understanding for the reader.

This area looks a little confusing, perhaps could try reducing the amount of nesting occuring?

These two methods look very similar, perhaps you could just combine it into one instead of duplicating it?

Comments are written for the reader and explains what the class Deadline is. Perhaps you could include these in your JavaDocs. Good job 👍

Since this portion of code is commented out, perhaps you could consider removing it?

Perhaps you can consider arranging your imports in lexicographical order to ensure that the ordering of import statements is consistent. Consistent ordering of import statements will make it easier for readers.

I noticed that the indentation here is 10 spaces instead of 12 spaces. Apart from this, I believe your indentations are very well done 👍

Hi Wang Mo, I noticed that some imports are not arranged in lexicographical order. For example, 'duke.exception.InvalidInputException' import could be placed before 'duke.ui.Ui' and 'duke.task.Task' import could be placed before 'duke.ui.Ui'. This would make the ordering of import statements more consistent.

To add on, I like the clear and concise Javadocs you have written. Your code is enjoyable to read as well 👍 .

There are some issues with the indentation in this class. For example, the expected number of spaces should be 8 instead of 12 in line 40.

It appears to me that this import was not used. Maybe you could take a look and check if it could be removed?

I noticed that the '/' was not preceded and followed by whitespace in this class. Great job on ensuring that operators are surrounded by whitespace in other classes 👍

Hi Tiffany, I noticed that some imports are not arranged in lexicographical order. For example, 'duke.tasks.Task' import could be placed before 'duke.util' packages. This would make the ordering of import statements more consistent.

I also noticed that the .class files are in your main folder. If I am not wrong, intellij should auto place the files into the build folder? Perhaps you could take a look into that. Cheers 👍

Perhaps you could leave a new line to group your imports, similar to your other files

Maybe can consider having a empty new line to group your package/import statements

You might have missed a whitespace here

You might have missed a white space here

Not sure if this would be necessary as it is simple enough fro a reader to understand

Perhaps you could leave a new line to group your imports?

Imported classes should be listed explicitly.

I think you missed out on some white spaces in your switch statements

Should final variables be all caps?

Also should associated constants be prefixed by a common type name? so that when sorted alphabetically they will appear together.

Missing white space after comma

Perhaps for Strings like bye and list, you could use an ENUM class or private static final String variable instead.

Similarly, "E" and "D" could be abstracted away to either ENUM or private static final String variables like Event = "E" for more clarity.

Hi, I am not very sure however, I think only when you are breaking the line then you would need to use 8 spaces for the next line, however, for method and constructor, I believe you should use 4 spaces instead? Do correct me if I'm wrong! (This applies to the other classes as well)

Perhaps for cases like these where there are long String of texts, you can consider abstracting it out as private static final String or can consider an ENUM class too! Applies for other parts of ur code too!

Slight note for consistency. There seem to be some javadocs with full stops while some without perhaps you can choose to settle on one?

Some Javadoc format issue, there should be an empty line between the description and your @tag

there seems to be an awkward space in level 17? not sure if it is my computer issue

I don't think that there should be 4 spaces for the switch-case. I think there should not be an indentation there. Do correct me if I'm wrong

From here it seems like you named your overall Exception as CustomException, would it be better to make it more relevant to the project like perhaps DukeException instead?

It might not be too good to catch all Exceptions! This is because you might not know if it is an exception like RuntimeException would could be possibly due to your code itself, so it is a better practice to catch specific exceptions.

variable name should follow camelCase. This applies to the parameters as well

Maybe making Task class abstract is better so that there is no need for default methods and not every one of the subclasses need to use @Override for saveString() or any other possible future overlapping methods that are implemented differently across the different subclasses.

Feels really messy. Since strArr already has the command string in the 0 position. Can consider using a switch statement to check for command for readibility purposes. Instead of a mix of userInput.equals and strArr[0].equals. The logic after each else if/else block (or switch statement if u choose to use it) can be broken out into private methods like others mentioned for readibility.

Readiblity is quite poor here 😦

Switching the if else checks around would allow you to skip '&& (arr[0].equals("todo") || arr[0].equals("deadline") || arr[0].equals("event") ||

            arr[0].equals("done") || arr[0].equals("delete") || arr[0].equals("find"))' just checking for length instead.

So:

if statement 1) command I don't understand? (ignoring description)

if statement 2) command without description? (all commands here would be understood)

Instead of:

if statement 1) command without description? && command I understand?

if statement 2) command with description but I don't understand?

Comments would be nice to describe what is being checked at each if statement.

Do also consider using the logic under 'public String parse(String userInput, Duke duke)' to avoid doing checks on the command string twice to keep maintaining simple (ie don't have to update 2 places when commands change).

I assume these two values are the 'tick' and 'cross'. Consider using a named constant as part of keeping code quality, avoiding magic numbers.

Maybe naming could be better. For me, Mug doesnt invoke thoughts of a tool to save task 😕

I can only assume isTime is about if whether the time component is missing for the input string. Naming could be better and @param isTime About time. could describe it better as well.

TaskList should not be handelling the making of an Task object. Could offload to the Parser class instead.

Magic strings here :c Avoid. Also I don't think string building should not be the responsibility of deleteTask method or TaskList class at all. Consider outsourcing to another class to make it less complicated.

Same issues here as deleteTask(int taskId) (Magic strings here :c Avoid. Also I don't think string building should not be the responsibility of deleteTask method or TaskList class at all. Consider outsourcing to another class to make it less complicated.) . Can generalise this problem for other similar methods.

Some Deadline references here, I'm guessing its a copy paste mistake.

consider splitting these parts out into private methods for readibility purposes

Would you consider importing each one of them rather than having *?

Maybe this could have been abstracted as method of another class such as TaskList?

Would you consider to add spacing before ">" ?

Would you consider adding Punctuation and the detail of the parameter?

Would you mind adding punctuation after the description?

Would you consider deleting the file as it is no longer used?

Would you consider putting this class at some package?

Maybe this line is not needed?

Maybe we need newline at the end of file?

I like how you separate this long string into different lines, but perhaps it is better to have breaks before operators?

'''suggestion

            "     Noted. I've removed this task: \n"

            + "       " + task.toString() + "\n"

            + "     Now you have "+ taskList.size() +" tasks in the list.\n"

'''

Perhaps it is better to put break before operators? I noticed the same issue in several other places too

'''suggestion

        throw new DukeException("☹ OOPS!!! Please put a number to select a task for the \""

                + commands[0] + "\" action!");

'''

Perhaps not having any indentation for case clauses will help improve readability?

Perhaps the name could be changed to isCompleted to sound like a booleans?

Perhaps leave a space after the argument closing parenthesis for better readability? I noticed the same issue in several other places too...

'''suggestion

public DukeIncorrectTimeFormatException(String message) {

'''

Perhaps handleUserInputs will make a better variable name here?

Perhaps you can add a space after each if block to help increase readability.

Can I clarify that 5 here comes from length("todo ") ? If so, perhaps it is better to use length("todo ") or a constant here instead of magic numbers?

I noticed similar issues in several other places too...

Perhaps taskList will give a more clearer context instead of shelf?

Perhaps you mean || here? I noticed the same issue in several other places too..

Perhaps a more intuitive variable name here? If I understand correctly, it is used to determine the index of task in your tasklist, so perhaps taskIndex ?

maybe can delete this extra space

maybe can delete this extra space?

maybe set isComplete false by default so no need to assign isComplete every time making deadline (same applies for other task related class)

ex) new Deadline("task", false, 2020-9-1) => new Deadline("task", 2020-9-1)

this is minor detail but can remove this extra space

can delete extra space

maybe can make each command's string as enum?

I think class needs to be part of some package.

like how all command is checked

shouldn't it be setDone?

need space between Exception and {

needs a space between while and (

The boolean isFound might be redundant since the toString() method for string builder will return an empty String if nothing is appended.

Consider catching a more specific exception such as DateTimeParseException that is thrown by the parse method when the text cannot be parsed. Hovering over methods can provide some information on specific exceptions thrown by library methods.

Nice implementation for parser, I could learn from this.

Interesting implementation for storing the tasklist, learnt another way of approaching this from your code. I only stored the task list when the bye command was issued but yours was to store every time commands were entered

You could try leaving a line between the description and parameters in the javadocs for your constructors, might have missed out that small statement in the coding standards 😅

Consider extracting out the lines of code into a function for the case statements to make the code look cleaner 😃

Would it be better to extract out the logic for case "done" into a function to make the switch case statements look cleaner?

For the case bodies consider extracting out the lines of code into functions below to make the entire switch case flow look neater like how it looks like for case "list" and "bye"

Would a more descriptive name for the date like "deadlineTiming" be a little clearer for readers? Calling task.getBy() might not be that obvious for first time readers.

Similar comments on regarding the deadline.

You might have forgotten to leave an empty line between the description and the parameter section for the constructors 😨

The cases should be on the same indentation as switch

How about renaming the method to showEmptyList? Not a coding violation, but showNoTask might not be easily understood

You might have missed out the empty line between description and parameter section.

This comment is missing the empty line between description and parameter section as stated in the coding convention page. Happens a few times in this class, so I'll just comment once here!

This comment is missing the empty line between description and parameter section as stated in the coding convention page.

Maybe setting display as final which is also consistent with date? 🤔

Not sure if static is necessary though since there are no static methods in DeadLineTask and it is set as private. What do you think?

It might be a good idea to move all Ui related components to a UI.java class. What do you think? 🤔

In this case maybe a UI.welcome() to print the welcome message?

Maybe naming it something else other than MyDateTime so it gives a little more information?

Maybe its a good idea to declare a variable like String task = info[0]; so that it is less ambiguous what info[0] is? 🤔

Should printing be done in Storage and not in the main execution? 🤔

Would it be better to have a UI.class to handle formatting text and display a printable message to the user? For example parsing storage.get(position - 1).toString() into a UI.markAsDoneMessage(storage.get(position - 1).toString()) ?

Since you have a getDescription() method, would it be a good idea to set name as private? Also maybe we can also name it something else rather than name so it is more descriptive?

It might be better to name this as canExitProgram since this is a boolean to check if program has terminated?

Perhaps instead of naming it c, name it command so its easier to read? 🤔

Maybe it is better to name this as getTaskListWithKeyword instead of an overloaded method so that the functionality of the method can be easily understood without reading the docs? 🤔

Perhaps this could be named as getTaskListOnDate ? 🤔

Should there be spacing here?

As in for (Todo...

Perhaps a space here?

Between for and the bracket.

Perhaps list your imports explicitly?

Any reason why you use isFileExist() instead of doesFileExist()?

I find that it reads easier the other way.

Any reason why you abbreviate the method? readTextFile2List() struck me as a method to read a second text file into the list before I realized the short-form.

Perhaps you could format your test methods in the following way so that it is easier to understand?

featureUnderTest_testScenario_expectedBehavior()

Same thing for this class, perhaps you could rename your test methods so that it is easier to understand?

featureUnderTest_testScenario_expectedBehavior()

I like how you did the check for the command's follow-up details!

However, I can't help but notice you use a lot of numbers for your comparison and substrings. Is there any reason you do this instead of using a constant?

Like previous, is there any reason you avoid using a constant for your substring() method calls?

Yes, if you could write that line before line 58, then the conditional check will no longer be needed and the code will be easier to read.

Any reason why you don't use a constant?

Maybe line breaks should be used for this line to improve readability?

Should single statement conditionals be wrapped by curly brackets or not?

Should conditional statements be placed on the same line or separate line?

Should logical units within a block be placed together? Maybe separating them by 1 line could improve readability

I like how you use switch statements instead of the usual if-else statements here! 👍

Could this text be too long?

I like the use of switch cases here instead of if-else statements 👍

Maybe a line break could be used here to improve readability

Could the length of the line be more than 120 chars?

Should javaDocs be added here since this is a rather long line of code?

Could this line be more than 120 chars?

Perhaps it will be better to write the long form of 'tmp' to improve readability? I am not sure what it means

Maybe you can consider adding breaks before some of the dot separator for this block of code to improve readability?

The test method name can be more descriptive for readers to understand it better? There's the three part format featureUnderTest_testScenario_expectedBehavior() that you can consider adopting:)

Perhaps you can include in the name what you are serializing to make it clearer?

Maybe can use the long form to make it easier to understand, I am not sure what 'ctr' means from this line

Yup, I agree! I think 'hasNoArgs' may be easier to understand than 'isNoArgs' 😃

Perhaps 'tasks' should be entirely in uppercase since you marked it as a constant using 'final'?

Below you have a function 'add' to add Task t to the ArrayList task, should the statement still have 'final' inside then since the array list will be changed? It may be less confusing to remove the term 'final'

'done' here could be changed to 'isDone' to sound more like a boolean

I agree, since 'desc' is used in quite a few places, it may be better to use the full name 'description' so that it will be clearer in other parts of your code

Perhaps you can break before the operator '+' to improve readability

Good to consider and add such a scenario in!

The class has a clean structure and the methods are following SOLID principles well.

It is nice to see that you have created subclasses of the Command superclass. This guarantees a clean structure as different types of commands can be managed separately. Well done!

Definitely a nice and clearcut way to manage exceptions!

Maybe consider if you want to differentiate between lowercases and uppercases? And also, if you wish to search for matching elements in the date and time for events and deadlines as well?

The namings of methods as such are quite clear and direct 😃

Same as hanweic53 has commented, it could be possible to modify this naming a bit so that it might sound clearer 😃 The descriptions for methods are quite clear though! Nice attempt!

Same as hanweic53 has pointed out. It's a minor issue, but it might be good to take note!

The coding style for this class is especially impressive! Very clean and tidy. Keep up the good work!

Maybe consider indicating "@Override" here?

Yes, "tokens" is quite a good name to use! "loaded", however, could seem a little bit confusing.

I like how you arrange your import statements tidy and in order!

Perhaps you may consider avoid deep nesting (up to 3 levels of indentation) here to make the code more readable.

Perhaps you may consider change Task to an abstract class so that the implementation of getType(), getDate() can added later in child classes, instead of returning null value.

Perhaps you can consider get rid of so many empty lines.

Perhaps use Ui instead of Ui here since all class names must be written in PascalCase.

Maybe add an empty line between description and parameter section? I noticed the same issue in several other places too.

Perhaps you can consider adding a punctuation behind each description and no blank line between the documentation block and the method.

I like how you make all import statements tidy and in order!

Perhaps a more intuitive variable name that will sound more like a boolean?

Instead of keep repeating datearr[0].length() & datearr[1].length(), maybe you can consider putting them into a variable to make them more readable.

I like how you arrange classes in to packages!

I think it is recommended for variable names to be in camelCase.

This method seems a little too long. Perhaps it is better to break it up into smaller methods.

Would it be clearer to create a variable for such whitespaces and reuse it so that readers know their formatting purpose?

I think the code quality guide suggests that we don't use numbers to differentiate variables.

Maybe a name like getSize will be more descriptive

I think a name like printSuccess will make the method sound more like a verb.

This method seems a little long as well, can consider breaking it up. Perhaps it will be clearer to assign variable names to the numbers in this method so that readers can have a better understanding of what they mean.

I think imported classes should be listed explicitly even though I understand that you are literally importing everything from the package.

Perhaps a method name like getSize is more descriptive.

A name like getIndex may make it clearer what you are getting.

I like the additional help command that you have included 👍

I think maybe you can include javadoc to better explain the code.

I think you forgot to include javadoc for this class!

I think you forgot to include javadoc in this class!

Should the word 'load' be 'loads' ?

Maybe can include javadoc to better interpret the code!

Maybe can include javadoc in the exception classes as well if got extra time!

Should the word 'save' be 'saves'?

Maybe the DukeException can be split into more specific exceptions to polish the design?

Good job on explicitly stating the visibility of variables!

Maybe can try to include javadoc for methods in task classes as well if there is extra time!

I really like how to use inheritance to handle different types of command!

I like how you summarised the functionality of Duke concisely 👍

I like how the import statements are separated based on their association

Would it be better to just declare sc without the null initialisation?

Perhaps you can abstract out the common code

taskDescription = task.getTaskName();

Perhaps you can create a separate java file for this enum class since it is used by other classes too (DoneCommand, AddCommand, etc)

Would it be more readable if this was named INVALID instead?

Would it be better to name this 'Command' instead of 'Commands'? 'Commands' may suggest to the reader that it is a collection.

I like how these import statements are separated based on their associations 👍

Would it be better to make 'path' a private field for encapsulation purposes?

Would it be better to use a while-loop to enhance readability?

Might be better to name it such that it is a plural since it is an array. Perhaps 'currSubStrings'?

You can consider using Ui to generate the appropriate strings to be returned since your execute method already takes in a Ui object as a param. The same applies for the rest of the command classes.

Can consider using streams + filter to filter your TaskList to return a TaskList of only timedTask

Consider not making this method non-static and include a parser object as a field in Duke in order to call method

Good use of switch statements to make the code neater.

You can consider handling the respective commands (i.e trim and split the string command for "find" and "update") in their respective classes to make this chunk of code neater.

You can consider handling the conversion of the text data to the respective tasks in the Storage class, as the main purpose of the parser is to only make sense of the user input.

Good use of streams to filter and find the tasks!

You can consider using a UI class to handle the generation of the different strings to print. This applies for the other command classes as well.

You can consider using a better/more intuitive variable name for the storage field in Duke

Code here is not readable nor intuitive, can consider handling the parsing of input in DoneCommand and storage of task in Storage

Recommend you to create a different command classes for the various commands(i.e. DoneCommand, FindCommand etc) to better handle the user commands. This method is doing way too many things and is too long and convoluted

Feel like this is the job of a storage class, the TaskList class should only be responsible to adding a new task to the tasklist, deleting task from tasklist etc.

Styling error. Perhaps you could use the full word command as a more intuitive variable name?

Naming error. Perhaps you could use anchorPane instead of ap as the variable name?

Styling error. Consider following the style specifications for the switch-case block? Specifically, the indentation levels for the cases in your code should be 8 and not 12.

I like how you have abstracted the Command class. It makes the code much easier to read and understand.

Styling error. Consider using the full word "message" for the String variable name.

Styling error. Boolean variables should be named to sound like booleans. Maybe you can use isClear instead of clear here.

Styling error. Consider using full names anchorPane and mainWindow as variable names instead of short forms.

Great usage of the Optional class!

Styling error. Consider using time as the name for the variable instead of t. It will communicate the meaning in an easier way.

Styling error. Indentation for the for-loop brace is incorrect.

This is really nice!

Perhaps can break up this method into shorter methods?

Maybe the description of the javadoc can start with 'opens' instead?

Maybe extract out some parts of this method to shorten it?

Perhaps capitalise 'return' and maybe use 'returns' instead?

Perhaps the variable can be final, with a capitalised variable name as a constant?

Should the method come right after the documentation? I noticed the same issue in several other places too.

Perhaps you can capitalise ’Saves'?

Perhaps you can add the description for this method?

Maybe the name of this boolean variable can be changed to isCompleted?

Perhaps writing 'br.readLine() != null' will make the while loop cleaner?

Perhaps this method can be renamed as areAllDone?

Perhaps, you could add this file into git ignore as we do not need to push this data.

I think this new line is not necessary here.

The javadoc comment would be great if if could start with a simple present tense verb like 'Gets'.

I believe there needs to be a fullstop after the sentence ends.

Perhaps, the parameter i could have a better name, like index, or indexOfItemToDelete.

Perhaps the newStatus could be better named as a boolean variable like isDoneNow.

It would be great if the sentence ended with a period.

I think you could leave a whitespace between the slash and the start of the comment.

This name sounds like a variable name instead of a method, how about something like hasExit() or willContinue() ?

Perhaps the method name could be a verb like convertToFileStringFormat().

Right sure!

Perhaps you can change the name of Deadlines to Deadline? To match the consistency of the class Task.

Similarly for this, maybe change it to Event?

Similarly consider changing to ToDo?

Maybe change this to loadTasks? Since there is another method named load for the Task class

Maybe change this to showErrorMessage? Just for clairty ><

Maybe instead of by, you can try dueDate?

hmm you can try eventDate for this? Makes it a little more readable!

Perhaps you can write the exception it handles? I.E: throws SparklesException when the file is not found?

Maybe you can name it showListSize instead? Since all the other methods are named showLine/ showLoadingError

Maybe you can rename it getListSize since it is a getter ?

Could the variables for be more descriptive? That is, instead of o, be obj, and instead of c, be cmd

Should they have been private instead of protected?

should this have been renamed as tasks?

Should there be spacing between +"." ?

Should there be spacing between if(..)?

As mentioned by HCY123902, could this have been a series of if-else statements instead?

Should there be a line break between the import statements here?

is isExit, rather than this.isExit, sufficient?

Should the method be renamed as addTask instead to be consistent?

As per addItem, could this be deleteTask instead of deleteItem

For the javadocs, there should be a spacing between description and @param

This execute function is quite long. Maybe can break up further into parts for better readability?

Maybe this can be made protected as there are classes that extend from it so they can directly access this variable instead of using a getter.

Maybe can break this block up as there is a lot going on this one block. It was quite difficult to trace through.

Should be consistent with naming functions for example adding the public

There should be a gap between the description and @params for javadoc

variable name for arraylist should be in plural form

For your functions, some of them have a whitespace at the brackets while some does not. I think with the checkstyle one it is preferred to have the whitespace

should declare this as private

Could have better naming for the arraylist

is there any reason you chose to call the Exception 'commandNotFoundexException'? why not call it commandNotFoundException

since this is a final field should call it SCANNER instead of scanner

might be better to call this method handleException as handle appears to be rather vague

could call this showAddedTask

could call this showTaskList

could call this showDeletedTask

(just a suggestion) perhaps you could store the tasks in the same format as when the user inputs them/when you print the message on the console?

could u split this into 2 lines? (improve readability)

remove blank lines

i think it would be helpful if you include what the parser is supposed to do

Do you think it would be good to specify what this 4 represents?

Since this if statement has a long condition, perhaps you might want to display each new condition on a new line to improve readability?

I have also seen this case a few other times in your code.

Perhaps you might want to store variables containing these magic strings to adhere to coding guidelines?

Perhaps it would be better if your booleans can adhere to the coding guide:

e.g. isNotExited

I think this comment could perhaps be rephrases to be aligned with the Java Docs principle 😬

Perhaps you would want to rephrase it to Parses input from the user?

Perhaps you could add an extra space between Task and { to follow the coding standards and practices?

I like how you separated this long string concatenation into 2 lines, while leaving 8 spaces on the second line! This adheres to coding standards. Good job.

since rewrite is a proper word, perhaps you could just name this method as rewrite?

I like this one-line ternary operator!

Since you have the same string twice, would it be better if you store the string in a variable and then use it in your output and return?

Shouldn't there be a space after the comma?

Shouldn't variable names use camelCase instead of snake_case?

Shouldn't the indentation be removed for case clauses?

Shouldn't there be a space after the comma?

Perhaps consider having consistent indentation?

Shouldn't variable names use camelCase instead of snake_case?

Shouldn't the boolean variable be named isComplete instead?

Shouldn't the indentation for wrapped lines be 8 spaces?

Would it be better if the method were named getDateFormat?

Instead of using nested try-catch blocks, would it be better to use one block to catch different kinds of exceptions and throw the corresponding DukeExceptions?

Any reason why the string is joined this way? Maybe could the task contain a method to return a customized message instead?

I like your use of enum. It makes the code easier to read 😃

Perhaps a more intuitive variable name here? Like dueDate instead of by.

Perhaps a more intuitive name here? For example, eventDate for at.

Perhaps a more intuitive variable name here?

Great effort here to format all the different types of DateTime to parse for the user. It is user friendly 😃

Perhaps shorter the line for the reader to read the line better? Nice use of stream!

Perhaps a more intuitive method name here?

What does hydrate the task mean? Perhaps use phrases that are reader-friendly such as "Load the saved data from the disk"

I like how you implemented the Deadline over here.

Should this start with "Adds task in the command..."?

Should there be an empty line between description and parameter section?

Should there be an empty line to separate different import?

I like how short and sweet your Parser is!

Should this boolean be named as isExit?

Maybe can consider using "switch"?

Well-written Javadoc comment that handles the singular and punctuation well.

Should this ends with "."?

Maybe you miss out the "." here

Did you miss out the "." here?

Maybe can extract the split part to make it easier to read?

maybe it's better use uppercase and underscore to name a constant value?

Maybe can consider swap your if and else block to "make the happy path prominent" according to textbook?

Maybe can consider save the path in a constant? It makes it easier to access in write to file method (instead of calling file.getPath())

I think "list" would be a better name.

Group relevant import statements together.

Method name should start with a verb.

A JavaDoc for the method will help others to understand this methods better.

"+" should be at the start of a new line

maybe savedFile is a better name?

Maybe a more detailed name for date2 can be used?

I think there is a typo, "add a Command" should be "add an Event"? 😅

Did you miss a space before this line?

Cause you had spaces for your other JavaDocs comments 😃

I think names of Collections should be plural?

Should the "case"s be on the same indentation as "switch"?

Maybe a more detailed name for date2 can be used?

I think pathname should be in camelCase?

Maybe could be a bit clearer on what 'by' is? (e.g. byDate)

Similar to Deadline, maybe be a bit clearer on what 'at' is?

I like the readability of the if-else statements here. It's easy to look for a specific command and see the code for each one 😃

Can be abstracted out as a Parser class

Can be abstracted out under UI

Can be abstracted out as Storage class

Can be abstracted out as another class

Good use of Optional class here

Maybe can spell out "message" here

Can spell out "description".

Maybe overriding is not necessary as it is same as Task superclass

onList can be a bit misleading, can use printList/printCurrentList

onFind can maybe be replaced with printSearchedList/showFindList

Perhaps the first word should be "Constructs", as in a verb ending with an "s"? I noticed this similar issue for a few other Javadoc comments but most of them do follow this coding standard rule, which is great!

Should the lines be broken before the + operator rather than after?

Should underscores be inserted to separate the words in the variable name i.e. "BY_OR_AT"?

Should the variable name be "HOME" with all uppercase letters since it is a constant?

Should the variable name have a plural form (e.g. "tasks") since the variable represents a collection of objects?

Should the variable name be a noun (e.g. "stringToFind") rather than something that starts with a verb?

For the "that" variable, perhaps a different variable name - one that explains the variable to the reader accurately - could be used instead?

Should the variable name here be in plural form, as in "results", since it represents a collection of objects?

For such a variable name, and for its purpose and description in your code, would a boolean be a more appropriate type for this variable?

Should this method be named "getTask" so as to inform the reader what exactly it is getting? I noticed that other methods here such as removeTask() and getSize() are named in a way that makes it clear to readers what they do, which is great, and perhaps renaming this method would be consistent with this style as well.

Is it possible to further abstract the code? This style of deep nesting is not encouraged and you might have to organize the code again.

Would it better adhere to coding standards if you added white spaces before the "(" and after the ")" ? This style appears quite often in your code so hopefully you take a look at it again.

Do you think you can abstract this expression? This is rather complicated to look at if the person is looking at the code for the first time. You might consider:

boolean isInputTodo = parser.isTodo(input);

boolean isInputEvent = parser.isEvent(input);

boolean isInputDeadline = parser.isDeadline(input);

This is to further enhance the readability of the code, but this is just a small comment.

Should there be punctuation behind the parameter description?

Would it be better to list out all the imports for your command package? This might be an issue on Intellij's side as they group together imports when there are several

Should this TODO be empty? I think you may have missed this after completing the work

Should you use "Tries" instead of "Try" to conform to coding standards?

Is this a typo?

Is the implementation meant to be as such?

I think there should be spaces between each variable here

I think the naming of the array here should be in camelCase?

I think java reserved words should be followed by a white space

Similarly, I think its lacking some spacing here for the try and catch statements

I think a newline should be included here?

I think test method naming should be in camelCase? Likewise for the other test methods names

I think the indentation on this switch statement is not in line with the coding standard

I think it would be better not to use wildcard imports

I think the + operator should be on line 32 instead?

Likewise for this + operator, I think it should be on line 20 instead?

was this file in a package?

Could the exception e be mroe descriptive?

What does name refer to here? the command (todo, deadline), or the description of the task?

should there be an empty line after the comments, before the @params?

Should the class be declared public? (could it be just class Duke { ......} )

Should there be an empty line after class declaration?

Should there be empty line after comment, before @params?

Should there be an empty line here between javadoc and method?

Should variable names be more descriptive?

Should there be empty line here

Consider separating imports into groups, and in lexicological order.

The case line should be at the same indentation level at the switch statement.

"Mark" should be "Marks"

Consider separating different logical units with a line break.

From the java coding standards: "Logical units within a block should be separated by one blank line."

Consider leaving a line before the try block?

Variable name could be more descriptive.

This block is generally abit chaotic, perhaps add in line breaks to separate different logical units?

Javadocs:

"show" should be "Shows"
add a full stop after the function description

Perhaps return an immutable object of the class? (i.e. Instead of mutating the value of isComplete)

Consider importing in lexicological order.

Maybe a more descriptive name for the variable c such as commandObj could be used?

I like how your code checks and maintains the state of the Duke application. This can help prevent the program from behaving in unexpected ways.

I like the addition of this feature, it could come in handy for the user.

Maybe it would be better to give a short explanation on how the command is executed?

Perhaps more information could be given to explain that Command is a super class for the various types of Command objects, and that the role of a Command object is to create the correct type of Task and pass it to Ui for the correct string output to be printed.

I like how you have used a class to encompass all types of commands as this is neater and more scalable.

@w-yeehong that is a great point. I agree with what w-yeehong has mentioned, maybe you could remove the parameter completely as the method setDone is self-explanatory and a boolean argument may not need to be passed.

I like how the indentation of the value for cssLayout makes it neat and easy to read.

It is great that only the necessary import statements are written and * is not used to import everything.

I like that the JavaDoc comments are concise and informative

Maybe there can be some comments for this private method? Just to give viewers some idea on how the bot is initialized 👍

Not a huge issue, but since searchParameter has a this reference, perhaps it is better to standardize results and searchParameter to point from this as well! 😄

perhaps this method could be named more explicitly, for e.g. parseStringToLdt, so that more context on what the method is about could be given! 😄

I think you might have missed out a javadoc for this method! This applies for your Event class as well.

A very small issue, but perhaps the junit libraries should be imported before the dependencies needed to run your tests (i.e. junit imports before your exception imports).

Perhaps this variable could be a little more descriptive!

Small issue, but perhaps the carryOn boolean can be named as 'isCarryOn' or 'shouldCarryOn' to sound more like a boolean!

For the parse method, it might be a better idea to split the implementations which parse individual commands into another method, this way SLAP could be achieved. 😄

Perhaps it is a better idea to specify the type of lines to be a List instead, in case further into implementation a different kind of list structure is used to store the information!

Since this getter gets the lines attribute, maybe getLines() is a clearer name for this method 👍

Is the nesting too deep? Consider abstraction to your other classes

Can we assume that all thrown exceptions are only due to invalid index (and not other unchecked exceptions)?

would a naming like "markTaskAsComplete" be clearer?

Unnecessary indentation

Since ToDo is-a task, would a name like ToDo be sufficient?

Is it necessary to wrap it in 3 lines? line 36 should be indented a further 8 spaces, I notice this in other places too

Is this needed?

Is there a better variable name such as gibberishInput ?

Is the overqualified 'this' necessary? https://se-education.org/guides/conventions/java/index.html under variables

LOL

'final' variables are constants and should be spelled in all uppercase

You can actually use switch for this, it uses the .equals() function on strings, so you can consider that option!

Maybe include in the javadocs why you have 2 different constructors? Not necessary but would likely make for documentation that is easier to understand

Should be "Splits", note the tense and capitalisation, also expected full stop at the end

To quote the coding standard, "In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)", so something like "Adds tasks from given string format." will be better, also note the capitalisation and full stop at the end.

Watch the capitalisation and include a full stop at the end.

Similar to before, to quote the coding standard, "In method header comments, the first sentence should start in the form Returns ..., Sends ..., Adds ... (not Return or Returnning etc.)", so something like "Adds tasks from given string format." will be better, also note the capitalisation and full stop at the end.

Full caps naming is for immutable constants, you should perhaps include "final" to make these values immutable.

Maybe you should make this task private since it's not going to be accessed outside this class.

Mayb you'd like to print out the full formatted date and time in your expected output?

Perhaps this line needs no comments, it is quite self explanatory 👍

If you are declaring this as final, you may want to consider naming this in all caps separated by underscores.

Is it entirely necessary to have a duke package within another duke package? 🤔

I think you forgot to add the timing in here !! 🤓

If this is meant to be an error message, maybe it could throw an exception instead? 😀

Seconded!! Also agree on the succintness of the comments, keep it up! 👍

Hmm, this seems to be a constant, maybe you'd like to uppercase it with underscore? 💇

Perhaps you could rename it to "isLocalDateFormatted" instead, since the Date is definitely present, is just a matter if it is formatted correctly or not. Just a suggestion!! You do what you think is right 😺

I appreciate the humour here!! Though could the text be contained inside the Ui / Gui class instead for better abstraction? 💯

I think not having a newline at the end of the file might not pass the checkstyle.

(If you use the IDEA checkstyle plugin, the first line of this .java file will have red lines on it.)

Perhaps you might want to break this line for better readability(Too many characters):

    `return "[" + getTaskType() + "]" + "[" + getStatusIcon() + "]" `

          `+ description + " " + "(by: " + formatDate() + ")";`

Missing public class header comments.

Perhaps a name that has a better meaning is more suitable for arrays 😃

(It has to be plural too)

No header comments for public class and methods in this file. 😦

Perhaps try to use

/**

* Represents a parser that parses String inputs in the accepted formats into a

* {@link DukeDateTime} object.

*/

if the comment is too long and could not fit in one line? (Might not be a violation)

I think maybe the name of the String[] arr can be more meaningful.

Perhaps breaking the line from String commandName, so the nextline starts with String arguments) throws...would be better in this case?

(CodingStandard: Break after a comma or before an operator)

Maybe parsedInputParts is a better choice for this type of arrays since it needs to be plural.

Other case code blocks also have the same issue.

Perhaps getNumOfTasks as the method name is a slightly better choice.

(CodingStandard: Names representing methods must be verbs and written in camelCase.)

I think there should be a space after the comma?

Yes, I also found this in other classes i.e. method invalidInput() in Duke class perhaps can also be changed to a verb?

I like how you use String.format() here. I think it looks cleaner than using "+" for the strings concatenation 😄

Maybe the attribute name "at" can be changed to a noun like "date" or "eventDate" to enhance readability?

I think the import statements can be grouped based on their package and add one blank line between the groups to enhance readability?

I think "splitList" can be changed to something like "splittedString" to be more specific?

Maybe "splitList2" can be replaced with something like "deadlineDate" to make it more intuitive to the reader?

I noticed a lot of the method's name are not verb. Perhaps they can be changed to verb to enhance readability? For instance, maybe "byeCalled" can be changed to "handleByeCommand" instead?

Perhaps the imported class should be listed explicitly without using "*"?

Maybe "deadline" can be replaced with other name like "deadlineDate" to avoid confusion with the class name?

Good abstraction of a DukeException class

Maybe you want to rename the variable "by" as something like "deadlineTime"/"deadlineDate"? It could be clearer and easier for a person who doesn't know Duke Project to read 😄

I like the way you use ENUM to differentiate task types 👍

You may want to consider to use "eventTime" instead of "at"? Personally I feel it's more meaningful

Your switch structure looks good. There is no indentation for case clauses, and it comes with the default 👍

you may want to delete away these empty lines so that it will look neater? 😄

Yes, I agree with zhuoyao, it sounds more like booblean variable

I think names representing methods should use verbs, here, you may consider changing to names like "getDoneString", etc

You may want to use "getSize" to name this method? It will be clearer to show others what this method is doing.

And you may consider to use "final" to avoid changing this constant accidentally in the future

hmm, i feel its confusing to use verb as a start of variable name, as normally we use verb to start a method name.

hmm i feel this method is redundant

the vairable name should be all captical letter if it is final?

instead of print the task list, this method actually just return the printing message.

i feel "printByeMessage" maybe a better naming

return type is missing

why is this method empty?

Naming for final should be all capital letter?

you can use ++ length on here directly instead of writing line 48

maybe you can write this outside the for loop before line 58?

Try not to shorten variable names so that they can be more easily understood

Again, try not to shorten variable names. For boolean variable names, name them in the format is____ instead

should be case BYE, case LIST, case FIND, etc.

Try to follow camelCase and avoid abbreviations for variable names

Name it File variable as file. f is supposed to be used for scratch variables (i.e. short term use)

Use a more meaningful argument name

Try to add JavaDocs here if you have the time, as well as the other private methods in this class

Small thing but if you consider goodbye as one English word, method should be named goodbye() instead

Try not to use abbreviated or shortened argument name msg

Try not to use shortened names for variables so that the variable name makes more sense

Could have better names for your variables. I have no idea what str does just from the name. Or maybe you could add a comment to explain what it does...?

needs a space before '{'

Needs a space before '{'

Needs another space here too

Another space you forgot to add here.

This seems like a constant. Might wanna add 'final' to it as well.

You could combine lines 77 and 78. There is no need to separate them

Lines 48 to 50 could have been in a single line.

Lines 59 to 61 could have been in the same line too

A space is needed between the description of the method and the tags following it.

Method name is slightly vague. Could perhaps be renamed to processAsDone.

You could perhaps provide an alternative method description as this description is not indicative of the current method.

There isn't a need for filePath to be static.

Could perhaps include javadocs for to describe the class.

Naming for method could perhaps be more descriptive.

Variable name can be renamed to pathName

Leave a line after the description.

Could consider abstracting our each arguments and put them in a variable to make your code more readable.

Could perhaps be create a command class to encapsulate all the commands to adhere to the OOP concept.

Perhaps a more descriptive variable name can be used instead (duke?)

Maybe the boolean variable should be named to sound more like a boolean (isDone?)

Just a small nitpick, I think you missed out an empty line between the description and parameter section.

Perhaps you can split and name the components right from the start for 1, 2 and 3 to make the code more easily understood.

I think you are missing the javadoc for the class, oops.

Sorry just feels like result is a little vague here, are you referring to the response instead?

I like how your code is kept short and sweet in the main start method. Good job!

Perhaps you missed out on a @return for this javadoc? Your description seems to have an extra "the" too!

Perhaps a more descriptive word could be used for scanner? (scanner or sc) Just a very small nitpick.

I like the use of this class to store the countless printing messages for Duke. Great job!

good use of enums!

perhaps you could add an empty line between the description and parameter section as per the java coding standard? (along for the other javadoc comments as well!) 😃

maybe you can add punctuation behind each parameter description? (as per java coding standards, and for the other javadoc comments as well!) 😃

should break be included?

should this method be split into more methods? might be harder to debug in future 😦

perhaps this could be its own method?

maybe this could be a separate method as well? or even two considering that there are around 3 if else blocks!

maybe you can add a empty line between the description and the parameters? (as per the java coding standard - also applicable to the other javadoc comments!) 😃

thought this method was really cool and unique!!

good testing!!

Can be removed if commented out, leads to some confusion.

Can be removed if not used

variable name can be index or serialNumber instead of i to denote what it is

it should be named printTask instead of taskPrint

once again lot of these commented out lines should be removed

It should be PrintListCommand

Should replace with TODO, EVENT, DEADLINE

Very clear and concise and easy to understand, good job

Maybe class can be named EventTask instead of Event, makes it more clear

naming it list can be ambiguous, maybe it can be called taskList to make it clearer

Agree with the previous reviewer! Grouping all your Errors in one Enum class makes the code neater.

On another note, noticed you added a header comment for the Command Enum class. For consistency, perhaps one for this class too?

Found a hard catch here: misaligned asterisk. Sneaky.

Here, maybe start with Marks... instead of Mark...?

I noticed the same issue in several other lines too, but as the previous reviewer mentioned, this comment could prove redundant.

JDoc seems to be against any "blank line between the documentation block and the method/class." Perhaps I can suggest removing the (unintentional?) blank at line 38 here.

Kindly survey the other lines, as I might have missed some other cases of this!

Referring to the JDoc for all rules (the one suggested for W3 was only basic + intermediate), the this keyword is best used "only when a field is shadowed by a method or constructor parameter".

In this case, since path does not shadow any of the TaskManager attributes (taskList, ioParser, and textParser), perhaps it is safe and good practice to remove the this keyword.

Perhaps errorMessage can also be final?

Rationale: At any point, the code would throw new DukeException(errorMessage). Making the attribute(s) final is not only safe, but also recommended by JDoc as a good practice.

I like the different stages of boolean returns! To enhance the readability, you might want to consider refactoring different booleans. For instance:

'''

boolean isThis = ...;

boolean isDuke = ...;

boolean hasSameTasks = ...;

return isThis || (isDuke && hasSameTasks);

'''

I notice the same optimization could be applied to the 'equals()' method in other classes. Just a small suggestion!

Noticed that 'switch-case' statements were used in the 'Parser' class. If there are no method calls that prevent this, do consider 'switch-case' here too! It could potentially refactor out repeated method calls – in this case, 'inputList[0].trim().equals(...)'.

'''

String letterCommand = inputList[0].trim();

switch (letterCommand) {

case "D":

newTask = new Deadline(...);

break;

case "T":

newTask = new ToDo(...);

break

case "E":

newTask = new Event(...);

break;

default:

System.out.println("I'm sorry, but I don't know what that means :-(");

break;

}

'''

I like the usage of Streams here to filter relevant tasks!

Noticed that the method means to return UnmodifiableList. Would like to raise the use of Collectors.toUnmodifiableList() as a possible minor optimization.

Reference: https://stackoverflow.com/a/53013505

Really like that you consider using Java's Optionals to pre-empt empty tasks! Most people – including me – would stray away from this and bulk up on error handling instead. Kudos!

What do you think about leaving a whitespace after the //? I've noticed a few other areas with the same formatting

Since you are using input.substring(x) quite often in your code, what do you think about declaring a string constant for it and referring to it for the conditions? Such that the substring operation doesn't have to be repeated throughout.

What do you think about using LocalDateTime instead for the date/time related variables? Such that you don't have to parse the time separately

Do you think it would improve readability if there was a line break here?

Do you think it would be a better idea to give the test a more descriptive name? E.g. whatIsBeingTested_descriptionOfTestInputs_expectedOutcome. This applies to the other tests as well.

Do you think the naming for the methods can be improved on? e.g. deleteTask, addTodo etc because right now it follows a "set" prefix for completing, deleting, and adding Tasks which I find might be a little confusing 😅

What do you think about adding a descriptive header comment here describing the Duke class?

Do you think it would be better if you added comments for the class members as well?

Should there be a period after the comment?

Do you think it would be better to add a header comment here?

Great idea to offer a README! I will learn this from you.

Organisation is quite clear! Perhaps the invalid command case could be checked at the beginning so that the "happy path" is more clear ?

For this part, the "happy path" is quite clear 😃.

I do not think so, my concern is that doing so may violate the naming style? no?

I really like how you organise the commands into a package.

As mentioned, maybe adding some JavaDoc comments to meet our coding standard when you have the time 😃 ?

The parse method's structure is very clear!

Hi, Ashley-Lau, a gentle reminder : we need to meet all standards specified for reviewing. Perhaps consider phrasing your comments as question more often ?

I am having this issue as well. Perhaps we should shorten out method and use more helpers ?

Perhaps this method can also be shortened with the help of helpers?

Perhaps "secondarr" and "stringarr" should be in camelCase instead?

Maybe add a line break after the method description before parameter?

Perhaps you can restructure this code block to make the happy path more prominent?

Some of your logical blocks have a blank line before and after, some only before and some only after. Maybe you can make this consistent?

Perhaps an empty line between description and return section?

Perhaps add a verb at the start of this javadoc comment for this method?

Maybe use the "Returns" instead of "Return"? The imperative form is also apparent in many other javadoc comments of other methods. Perhaps consider changing them to be conform to the java coding standards?

I like that you placed line breaks in many parts of your code including this one. Improves readability. 👍

Maybe consider using a switch statement for this long list of conditionals?

Perhaps place the operator as part of the next line for ease of reading (easily shows that the line is part of the previous)?

This applies to other instances e.g. in AddCommand

Perhaps this (and other similar chunks of code) should be broken up into distinct logic units with comments to describe what they do?

Should this be in the featureUnderTest_testScenario_expectedBehavior() format?

If this is meant to only be thrown when an invalid input is given, perhaps a more descriptive name such as DukeInputException would help readability?

Not sure if I'm supposed to give this type of comments, but I think if your user input is something like todo delete files your parser will run the wrong command 😦

Good attention to detail to differentiate these responses 😄

Perhaps call these functions doSomethingSaveFile rather than doSomethingTextFile since you are referring to the save file all along? Could reduce some confusion.

Perhaps a more descriptive term than by can be used to describe the deadline.

Should this be protected? Not sure if used anywhere outside of getData() or toString().

Minor nitpick (that I'm personally ok with), but the coding standard suggests adding an empty line between the description and the parameter section

Not 100% sure about this one myself, but would a name like ParsedCommand be more accurate here since it represents one command? Though I understand that a previous level requires a class to be explicitly named Parser 😛

Since these are constants, it's recommended to have them all be uppercase (LINE, LINE_INDENT, ...). And perhaps that since they're associated with one another, they could also be prefixed with a common name (MSG_LINE, MSG_LINE_INDENT, ...)

The comments might be a bit redundant since the code already somewhat tells what is happening? But not sure.

Since these constants are associated, it might make sense to prefix them with a common name (eg. MSG_DIVIDER, MSG_GREETING, ...).

Another minor one, but the coding standard mentions that there's no need to indent for the case clauses.

Perhaps the last : "✓", line can be in the same line as the previous to improve readability?

Mentioning the reasoning behind the +1 might be a good idea

Consider naming x as a more obvious name (maybe returnValue?) just to make it clearer.

could perhaps consider using a switch statement instead of multiple if else

could perhaps rename type to commandType to make it clearer?

tasks instead of task

could perhaps rename to something more recognizable like dateString (?)

could perhaps overwrite the toString() method such that polymorphism can be utilised, rather than performing multiple if else checks!

adding on to the comment above about adding a toString() method, this could prevent multiple copy pasting of the same chunk of code 😃

could perhaps assign a variable name firstWord = input.split(" ")[0] so that it can be directly referenced in the rest of the if else statements!

could maybe consider using a switch statement instead of using multiple if else statements

could perhaps create a new Exception class to group this exception with the deadline equivalent

Perhaps userInput would be a more suitable variable name than searchText?

I like your suitable use of enum here!

Nice use of enum here!

Should the method be named more accurately with a verb, perhaps getWelcomeMessage()?

Should the method be named more accurately with a verb, perhaps getExitMessage()?

Should border be capitalised as well?

Would it be better if the DukeInvalidListNumberInputException was given a slightly shorter name, perhaps DukeInvalidIndexException?

Should the indent variable be capitalised if it was declared static final?

Would it be better to name constant (static final) fields with upper case letters?

There are opinions that nested ternary operators should be avoided as much as possible, as it's difficult to follow 👓

Could consider refactoring this code ⌨️

There are some magic numbers here (e.g. 7). It is currently not apparent to a reviewer, why you chose these numbers. Would suggest you refactor, index parsing logic into their own static methods.

That way, you could add comments to describe more about what the method does, and why chose those numbers.
Abstracting into individual methods would also make them unit testable, thus making your code less fragile

That said, the issues I have raised may not be urgent since they do not directly impact workability of your code. But they could be issues to keep in mind in the future 🐱 .

I observed that equals method is implemented for many of the Command classes. However, I am not too sure if it is actually necessary based on the project requirements.

In any case, if you decide to override equals, you probably should override the hashcode() method too. (See https://www.techiedelight.com/why-override-equals-and-hashcode-methods-java/#:~:text=Overriding only equals() method,hashCode method on each of)

If I were you I would probably save myself the hassle 🐩 and not implemented the equals method since it's not strictly necessary. But of course, that's just my opinion 😸

Comment should be removed when it's done 😝

Slight styling issue. The comment should probably be in the javadoc instead of inline. Writing it in javadoc would help you generate beautiful documentation too 😄

This chunk of code has quite a lot of logic in it 🧠

While that's totally fine, I would suggest to refactor part of the logic, namely (parsing index of task and getting task description) into their own separate methods.

Doing so will have a few benefits:

Abstracting into methods gives you opportunity to document them. Naming them would also make it more readable for the reader
Methods are unit testable. This gives more opportunity for unit testing and makes your code less fragile and look more reliable 💪

I find this comment, a little unnecessary, since we can infer that the line below is a String alr, what do you think 😃?

The additional noun here (mark_done) could be removed ☺️ Just verbs are enough if we are following our cs2103 coding style 🤓

Funny comment 😋. I love it, but some may find it unnecessary.

cool graphic 👀

The coding style for this module suggests we should have no indentation for case clause 😕

same comment as previous switch statement

I like your use of System.exit (cause I didn't use it in my own program LOL) 😀

Hello! You should have a newline at the end of your files if not you might get errors while doing checkstyle😰

Tiny nitpick here.. To improve readability of code, you could try using guard clauses to ensure that the happy path is more prominent 🤓 Click here to read more

Cool, never thought of using enum this way

same thing with the guard clause!! can refer to my comment above

wow, very neat way of taking in user input 👍

Oh but for this module, the case clauses should not have the extra indentation, can find out more here

Perhaps you missed out a merge conflict here?

I'd concur with the views above - hope the changes aren't much trouble 😃)

Explicitly listed, the classes would be BufferedReader, BufferedWriter, File, FileReader and FileWriter.

Perhaps a constant declared with final should be renamed in all-caps?

Perhaps an enum (say, ExceptionTypeEnum) would be more expressive here?

Maybe you could separate out logic such as this into its own method? This would help make the method shorter.

Perhaps this is a redundant check, as per the documentation of the createFile method?

Maybe this should be an exception instead?

Astute idea to separate out MainWindow as a UI component. Makes for a clean SOC between Duke and its UI!

this constant should be in all caps! COMMAND_LIST

you should specify when these exceptions are thrown!

eg @throws CommandNotFoundException If the user command is not in the command list

귀여워요 haha

those curly braces are unnecessary! i think the code would look cleaner without them~

you should use underscores to separate words! also, associated constants (final variables) should be prefixed by a common type name

eg PATTERN_EXIT, PATTERN_DONE

you should be able to combine these if statements into one!

if ( ... && ... ) { ...

if the first half returns false, the second half won't even be executed, so no need to worry about nulls 😃

you can collapse this into a single try-catch!

'try {

...

} catch () {

...

} catch() {

...'

you can also just surround the exact statement that might throw the error (in this case 'sc.next()')

you can use a switch statement instead!

same as before! minimise your try-catch coverage to error-prone areas and use switch statements~

Maybe you could consider adding javaDoc comments to help improve readability

This method seems to be a little long and goes beyond 30 LOC. Would be good to provide a javaDoc comment or shorten the code

Seems to be a long method would suggest shortening it and adding a javaDoc

the method seems to have deep nesting, maybe consider avoiding arrowhead style code.

Should this be more descriptive? maybe sizeTaskList

Should this be in camelcase since it is a variable

Maybe the method name could be more descriptive? Can consider getTaskDetails

Should variable name be in camelCase? maybe taskList would be better here

Should this be a verb since it is a method? maybe something like generateMessage?

Perhaps it would be better to move the import java.util.Arrays; statement to before the import duke.command.Command statement?

I got flagged for this by checkstyle myself.

Consider using braces for your if block here? It would adhere to the coding standard and be more consistent with the rest of your code as well

Maybe you can consider changing the class name to Dook as well to match the name that you have given it? I think it's better to match the class name with what you actually want to call him.

Might be better to give more descriptive names to str and args as they are used throughout this method for better readability. Also consider changing done to isDone to follow the coding standard.

Might be better to phrase To instantiate... as Public constructor for TaskList object that requires a Storage object or something along those lines.

Might want to change Add to Adds for to make it grammatically correct and more consistent throughout your code as I've noticed some methods use singular verbs in their description while some others use plural verbs.

nice

Is it necessary to have overloaded methods? It seems to result in some duplication of code in the implementations of your Command subtypes.

Perhaps write the comment above the corresponding line of code for better readability?

Maybe you can consider renaming this variable to something more descriptive instead of dth for better readbility.

Perhaps you could create multiple exception classes which inherit from DukeException instead of writing various methods in this one exception class.

You could consider using switch statements instead of if-else since there are many different cases to handle here.

Perhaps you can use more descriptive parameter names.

Should not have a blank line between documentation block and constructor.

Add punctuation behind each parameter description.

Empty constructor may not be needed here.

Perhaps make this into one line for better readability?

Should your class files be in a folder "duke", in lower cases instead?

There is a small typo here for the word "can".

Perhaps you might want to use a boolean value 'isExit' as the looping condition instead? You may refer to the example below.

Good practice to import classes explicitly.

Maybe an empty line between description and param section? This applies to the other JavaDoc comments in other files.

Perhaps you might want to improve readability by using a boolean value 'isExit' as the condition instead?

Perhaps you can consider listing the imports explicitly?

Perhaps numOfTasks() might be clearer?

Perhaps findTask(...) would be clearer? This will be similar to your other methods here too.

I understand that you avoid isQuit again because it has the same naming as the attribute. Perhaps can consider hasQuit() so it is clearer that its a boolean?

Just a suggestion but you can also consider the short form "init".

Maybe can remove the enter spacing here so it doesn't seem like a separate method javadoc

Once the code lines are not required, they can be removed. Else if its meant to be kept, you can consider adding TODO line so others know there are pending changes.

same for this as well! If comments are not required can remove them!

Can consider showWelcomeMessage so that other developers can expect string outputs.

I'm not exactly sure what "iteration 2 " means. Does that mean there is a another method that's iteration 1?

Just a suggestion: Maybe can rename them to TodoTask, EventTask and DeadlineTask so that programmers that doesn't know about our Duke project knows that an Event is a type of Task

I think its because it is not a requirement for the More-OOP tag but a good to have!

Oh I didn't know you can break the description into the new line and indent till the first word which makes the description much easier to read. Anyway, I like your Javadoc since it's really succinct and detailed. Learn a lot from reading your javadoc 👍

Just a very very minor detail here because of the extra empty line

Very nice and clear way of dealing with each type of command!!

But I think you don't have to have an indentation for your case statement, so case should have the same indentation as switch

Another very minor detail here also, perhaps you can leave a line between your package and your import statement. I see you do that for most of the other classes so maybe you just forget to do it here 😄

The summary of what the function does is great 😄, perhaps you can improve it even further by starting your summary with the verb Gets ... instead of a function to ... . I noticed the same issue at some other places too. You can view more about it here 😄 https://se-education.org/guides/conventions/java/intermediate.html#comments

I like how you break the line, you think can put the + operator at the beginning of the new line instead of the end of the previous line.

More info can be found here under the Place line to improve readability section 😄

https://se-education.org/guides/conventions/java/intermediate.html#comments

Perhaps you can try segment this code since it is a bit too long now imo, maybe you can consider an execute() for each command?

Just a very minor detail here, I think you can consider put the + in the beginning of the new line instead of putting it at the end of line 72 😄

Perhaps you can try to avoid putting all the processing of the input in the predicate expression for the if ... else, you can try to have another function deal with the parsing and isolating user input and just return what you want here instead 😄

you could have use this.message to make it specific the message reference.

"Task deleted" seems to be a coding standard violation. You could change to deletedTask instead

It's better to name out the exception you are handling

"list" can be changed to "TaskList"

Since the line is not to share with other class, maybe change it to private instead?

good use of switch case to list all possible outcome, adding a default may be better

saveTasks maybe change to saveTasksToFile to make it more specific

we are missing a verb before taskDone, maybe makeTaskDone?

input is not a good name for Scanner, maybe sc?

Variable should be named as PRE_SPACING

Does not follow the JavaDoc preferred style. Better if you commented as Formats the string to...

Too many empty lines.

Possible to use switch statement?

Avoid long methods.

Parser class should only parse the user input and translate to Duke-understandable commands. The specific execution of those commands should not be handled inside Parser.

Use a switch statement to enhance readability.

Avoid deep nesting.

This should be handled by Ui.

printAddedTask and printList should be handled by the Ui class.

Shouldn't there be a line spacing between the description and parameter section as specified in the coding standards?

I noticed the same issue in several other java docs too.

For line breaks, shouldn't we break before operators like '+'?

Maybe it's a good habit to include a @ Override tag here?

Maybe there is a more intuitive name than temp? Such as inputTokens?

Should the name of this method start with a verb to make it more intuitive? Maybe like convertFromFile() ?

Should there be indentations for case clauses?

Should there be a default clause here?

Maybe you can separate imports from different packages so that it will be easier to browse the list?

tokens is a good name for the this case. Not so sure about loaded though, although we know that it represents your loaded task after reading the code, but it's not intuitive at first. 🤔

I like how clean the code for your Storage class is but perhaps the two public methods (doesFileExist() & createFile()) could be made private?

I like how you segment the classes with "//Attributes, //Methods, etc." as it makes your code easily readable and clean. Perhaps you could also add some javadoc comments to methods that are not clear in what they do. For instance, for getStatusIcon(), it could be good to include what the output represented.

I like how clear the javadoc comments are. However, perhaps you could add an empty line between the description and parameter section. I noticed this similar minor issue in several other places as well.

I like how clear and easy-to-understand your Javadoc comments are. Perhaps for this comment, you could leave an empty line between the description and the parameter section to conform to coding standard.

I like how clear your documentation is. However, perhaps you need not repeat some javadoc entries for overridden methods. I noticed a similar pattern in several of your classes (Command classes).

I like how proper the naming of variables and methods are, making it clear as to what each variable and method does. However, perhaps you could extract out some components of the method into compact private helper methods to reduce deep nesting? I noticed similar patterns in a few of your methods.

I like how you included comments within the method to make it more readable. However, perhaps it would be good to extract out some components of the method to make the method shorter and easier to follow.

Perhaps you could add a "// Fallthrough" comment for leaving out the break statements.

Perhaps you could simplify the method by doing it in steps to reduce the amount of complicated expressions and improve readability of the code.

Should you remove the this keyword? The java coding standard documentation mentions to use this keyword only when a field is shadowed by a method or constructor parameter.

Should this be method be called setDone instead? See the boolean section in java coding standard

Should this be reworded?

Should you remove the this keyword? In the Java Coding Standard documentation called "Avoid unnecessary use of this with fields.", it mentions how the the this keyword should only be used when a field is shadowed by a method or constructor parameter.

Should this be renamed as toStream? It might be more intuitive instead of just stream.

Should this be abstracted to a separate method instead?

Do you think it's better to store the string template "Got it. I've added this task: ..." as a separate variable or abstract it out into another method? This reduces repetition as well as enable you to reuse the template in case you have different types of tasks to add in the future.

I like the use of the label although a better name could be used instead.

Should 'TaskList' contain 'Ui'? Your 'Parser' class contains 'Ui' as well. So you could invoke the methods for 'TaskList' and 'Ui' from 'Parser' instead of invoking some of 'Ui' methods in this 'TaskList' class.

An example from your 'Parser' class would be this:

'''Java

case "bye": { //bye

storage.updateFile(taskList);

ui.farewellMessage();

break label;

}

'''

This reduces the dependency between your 'TaskList' and 'Ui' class and allows your code to be easier to maintain.

I like that you followed the no indentation rule for case clauses

I like that you imported the following in order and did not make use of the *

I like that your javadocs follow the standard format (E.g. the spacing in between param and the description)

I like your use of variable naming, makes the code more comprehensive more readers

Perhaps you can consider listing explicitly all the classes of the Duke Package required for this testing?

I like your extraction of command classes, as it makes the code a lot cleaner and more comprehensive.

Perhaps the use of substrings and the significance of the numbers can be illustrated more clearly?

Perhaps there can be another javadoc here as well?

I like your thorough testing!

Just a missing spacing between ")" and "{".

Maybe put a spacing between ")" and "{"?

Good naming of the methods!

Just the missing spacing between ) and { in some methods. Everything is good!

Would it be better to name this method as "showWelcomeMessage"?

Would it be better if "showByeMessage" is used instead?

Maybe add a spacing here: "testGetNumTask() {" ? Also, would "listOfTasks" look better?

I think it's the same as above, just missing 1 spacing between ")" and "{".

Everything is good! Maybe just the missing spacing like above.

Perhaps comment on why the catch block is left empty?

Is there a way to make the method shorter?

Perhaps comment on the reason behind the empty catch block?

Should this be changed to increase readability and understandability?

Should there be a space above this line?

Perhaps remove indentation for the case clauses.

Perhaps align the case clauses with the switch.

Should there be a line break between static imports and normal imports?

I like how you listed the imported classes explicitly.

I do not think the variable named printAddTask is well named.Does printNewTask describe the action better?

Based on the coding standard, all comments end with a full stop.

Opps, you forgot to use the correct format for parse_FindString_prints as you did for parse_addString_prints. At least you did aware of you mistake and edited it for the parse_addString_prints.

Same thing happen here, is it better to replace the add to new?

setMessage(List, EventTask...) might not seem complete. Does adding a of or for help to make the variable name complete such as setMessageOfList?

Do not forget follow the coding standard for while loop.

Yes, I agree. Maybe instead of doing if-else inside an if-else, they can be a part of else if of the main if-else.

These exception is thrown due to the problem of reading data from data file or saving data to data file which are relative to the data file. Therefore, an exception named fileLoadingException inherited from Duke Exception can be created so that all the exceptions inherited from the DukeException can be handled easily.

The name of the function get might be a bit confusing. Is it better to be "getTaskByIndex"?

Based on coding standards, it's better to place the line break after a comma or an operator to improve readability.

For this part, is it better avoid nested try catch block to increase readability? Maybe you can extract each part separately into different methods 😃)

It's good that you have structured the code to deal with an error as soon as they are detected to make the happy path clear and prominent. 👍

Perhaps you can use a more descriptive variable name to increase readability 😃

It's okay, my variable naming is also bad sometimes ._. Yes, it's better! 👍

Based on coding standard, the Javadoc comments should have empty line between description and parameter section and there needs to be punctuation (a full stop) behind each parameter description.

Is it better if the loaded method is named as printLoaded instead to be more meaningful? 😃

There is a minor indentation mistake for switch statement. There should be a spacing between "switch" and "()". The indentation for other switch statements is good. 😄

Based on coding standards, I think no need to put curly brackets for case block.

Suggest using private keyword instead of protected.

different parts of the code can be grouped together as a method, make it easier for abstraction.

same suggestion as deadline

typo: should be re-enter

"Boolean variables/methods should be named to sound like booleans."

Recommend using canUnderstand instead.

I didn't know this way of using enum before, nice implementation! However, it may be better if you create a class for Command, according to OOP.

allTasks might be more intuitive.

hahaha i like the way you make it sounds so engaging!

new line

I agree with this. I noticed this issue in other files too, perhaps your IDE is not configured correctly.

Perhaps this variable could be renamed to tasks?

This isn't really a comment on code style, but there seems to be a lack of tests implemented for your PR. Maybe a few tests to check your program could be implemented.

Is this a leftover data file from running the application? Try adding the filename to .gitignore so that this file won't be commited.

I feel like this can be either renamed tasks or taskList but I feel like this may be subjective.

Maybe this should be removed? Or possibly throw an error/exception rather than a comment.

Could be renamed to sound more like a boolean, i.e. isCompleted.

This is more of nitpicking, but are brackets needed here?

Maybe this could be included in the javadocs instead of a separate comment.

Should this class variable be named "uI" instead of "ui"?

"Variable names must be in camelCase." - Java coding standard @ SE-EDU/guides

I noticed that there could be issues regarding the naming of UI objects in other classes too.

Perhaps, this class could be named "UI" instead of "Ui", since it is an acronym where both letters represent different words.

Class/enum names must be nouns and written in PascalCase. - Java coding standard @ SE-EDU/guides

It could be beneficial to edit the name of this class variable to include more detail to explain what this format could be used for.

For instance, maybe this constant could be renamed to "REQUIRED_FORMAT" to indicate that is the required format that users should use when providing input.

I believe that the Event class has a class variable named "FORMAT" too that could benefit from this small edit too.

Use name to explain - Textbook

Would it be better if the naming convention below was used for naming the test methods of this test class?

whatIsBeingTested_descriptionOfTestInputs_expectedOutcome - Textbook

Perhaps, the test methods in the other test classes could benefit from using the stated convention as well

I like that you created your own custom greeting banner!

Could a more descriptive name (such as fileWriter) be provided for this variable? Otherwise, it may perhaps be better to explain this acronym. Also, since each letter of this acronym represents a separate word, camelCase should probably be used.

Perhaps, it may be beneficial to provide a full word (such as result) as the name of this variable instead of an abbreviation. Otherwise, the provision of a brief explanation of this variable's name could be useful to improve readability.

I have noticed this issue regarding abbreviation in variable naming in other parts of code too.

Perhaps this variable could be provided with a more descriptive name to improve readability.

It may be beneficial to include a verb instead of having one noun to name this method, since it completes an action. For instance, including the verb "print" in the name could improve its naming.

Perhaps change this to index? In my opinion it's more understandable from the get go and it's not too many more characters 😉

Typo in 'specified' 🤣

Just a suggestion but I would name it as toReturn instead 😃

Perhaps you might consider changing it to formatMsg instead?

Perhaps you might consider capitalizing the start of each Javadoc comment to improve consistency?

Can consider shifting this comment to your Javadoc comment, under the description for @param description. Same comment for the DoneCommand class 😄

With reference to this:

Variables should be initialized where they are declared and they should be declared in the smallest scope possible.

I think you could consider combining lines 22 and 23 into a single line? Similarly for the DoneCommand class 😄

This comment was very helpful in understanding the logic flow of the app! 👍

Not related to the coding standard but I just wanted to say that implementing the Serializable interface was an interesting decision! I had never known about this until now, so thanks for introducing me this 😄

I like these error messages 😄

Since there is quite a lot of logic going into this method, should there be Javadocs for this method?

I like this method's name - wish I had thought of this 😄

Should there should be a line space between the header and the parameters though? Can also consider this with the rest of the Javadocs in this class and its subclasses.

Should the assertions import be split into individual imports?

Cool test case 😄

Can the name of the test case be clearer though? Something like parser_unknownCommand. Can consider this with regards to the rest of the test cases as well.

Perhaps you can consider renaming words to something like taskInfoWords to make it clearer?

Interesting use of the 'split()' method.

Perhaps you can consider abstracting '"T"', '"D"' and '"1"' to be a variable to make it more readable?

Something like:

'''java

...

private static final String TODO_INDICATOR = "T";

...

if (words.get(0).equals(TODO_INDICATOR))

...

'''

Alternatively, maybe you can create a method called 'isTodoLine(words)' to improve readability?

Perhaps the "1" and "0" can be defined as variables in Task.class? Then the subclasses can utilise these variables, helping to abstract this flag further since it is used in both Deadline.class and Event.class.

I like this customized divider👍 So cool.

I like how you kept an example of the subclasses of the Task class 😄

Perhaps you would want to put the toString() method below @Override ?

Can try using String.format() for a longer customised string 😃 , I noticed this issue in other places as well

Perhaps you want to put a space between the comma and the next word 😄?

I like how you abstracted Status into an enum 👍

Perhaps you want to make this field private? By default it is default access modifier 😄

Can perhaps abstract the different commands to avoid a long command? 😃

I really like how you included the clear() method and the code is very clean

Perhaps since this is a multi-part customised line you could use String.format instead?

Perhaps should put a fullstop after the sentence? Found this issue at several places as well

Perhaps you could consider re-factoring this method and make it a bit shorter so that it is more readable.

I like this method's design and comments provided! A smart design for date parser. 👍

I like this documentation- clearly explained the mechanism, advantages and disadvantages. 👍

I like the use of stream and method chaining here- very succinct and clear. 👍

It would be good if you can add a new line at the end of the file!

Same goes to here, It would be good to have a new line at the end of this file!

Should the first word of the Javadoc be a verb instead of a noun? Also, I believe that the first word after @param should have the first letter capitalised. 😃

Perhaps a clearer naming could be used here? I feel that foundList sounds like a vague name that can be used for both variables and methods.

I read the javadoc wrongly, sorry about my mistake!

Perhaps the class name could change to CommandDeleter or other nouns? Reference: Use nouns for classes/variables and verbs for methods/functions.

I like how you name your command classes which is pretty clear for me to follow!!

Ohh I think I misinterpret this as a verb at first, but from the rest of the class names, I could tell this is a noun as well

I like how you clearly named each of the exceptions from which I can instantly get the meaning!

I like the way that you name it as a noun instead of ParseTime!

Perhaps avoid using public here? Reference: Class variables should never be declared public unless the class is a data class with no behavior.

I like how you follow every rule of the javadoc

I like the ordering of your packages, but maybe move the javafx.stage.Stage package to the bottom?

I like how you follow the indentation rules in the try and catch block

Use nouns for things. Consider more descriptive names such as 'deadlineDate' instead of 'by'.

Personally, I think naming it as taskList is alright here. I think in the textbook when they are referring to constant variables, it's more like fixed values e.g. int MATH_PI = 3.14 . In this context, I would consider taskList more of a variable rather than a constant instead. 😃

Again, use nouns for things. Consider naming this variable as 'eventTime' or something rather than 'at'.

You may wish to consider combining the 3 "System.out.println(..)" into one e.g.

'''

System.out.println("Got it. I've added this task:"

                + task + "Now you have "

                + taskList.size() + " task(s) in the list.");

'''

Same issue pointed out by the first reviewer. Take note that there's no indentation for your case blocks.

Good job in following the coding standard for switch statements!

Consider naming your function by adding a verb (e.g. markDone) instead of 'done' as it may not be apparent what the function 'done' does.

Consider using 'deleteTask' as the function name as 'delete' may not be clear enough. 😃

I noticed that you have named the subclasses in plural form (e.g. Events, Todos, Deadlines) but they represent only 1 Task object rather than a list of event/todo/deadline tasks for example. Perhaps you can consider this point in future for clarity.

I agree with shermz-lim, there shouldn't be indentation for case clauses as indicated in the coding standard.

Perhaps the class name could be TodoCommand with d in small caps since your todo class has d in small caps. This ill make your code more standardised.

Same case here where case clauses shouldn't have indentation.

Should there be a line break here between line 67 and 68? I feel that there is no need for a line break as the line is not long when put together.

Perhaps there could be a line break here to improve readability of your code.

Should the method name be parseToDoTest instead? Since your todo class has a capitalised D. This would make the code cleaner and more standardised.

I agree with jimvae, you could provide further abstractions to make your code more easy to read.

I like how you personalised the project with your own naming and logo.

The line break is good as it makes it easier to read.

Should this indentation be 4 spaces instead of 2?

Should the indentation here be 4 spaces instead of 2? I notice this same issue in other places as well.

Should this line be indented so as to have less than 120 characters?

Should there be no need for indentation in switch statements?

Should the line break be 8 spaces instead of 4?

Should there be a space after i such that System.out.println(++i + ". " + task);

Maybe can consider using a more descriptive name that indicates a date/time object?

Perhaps can consider using a more descriptive name? I notice the same issue in the Deadline class.

Perhaps you can use something more descriptive like secondCommand?

I think because the constructor is also a public method the Javadocs comment should also start with a verb!

This method is quite long and exceeds 30 LOC, maybe you could consider splitting it up into multiple private methods?

Maybe you could also experiment with throwing exceptions from your Commands instead, if that would help trim down this method. For example, instead of multiple checks if num is outside of list index, you can catch the IndexOutOfBounds exception from your command's execute method and throw the required DukeException from there

Here and in other cases, because the constructor method is still a public method, I think the Javadocs should still start with a verb? eg. "Constructs a new ..."

Perhaps you can consider using descriptive constants to represent the numbers 4, 5 and 7?

Maybe the constant here could have a noun name, to avoid being confused with a method? The style guide also specifies that constants should be all uppercase using underscore to separate words

I think this parameter name would be clearer as a noun, eg. 'time' or 'dueDate'

Here and in other places, there should be punctuation behind each parameter description

Can remove the word "Thrown" here and in other instances? I think '@throws DukeException when ....' is meant to be read like a full sentence

Just a minor thing, but I think you don't need the conditional expression here since .equals already returns a boolean 😃

Should the name of a constant be in all uppercase instead?

Perhaps the imports from different packages could be separated to make it easier to browse the list?

Should there be a spacing between the ) and { ?

Perhaps the string could be more descriptive of what it contains? eg, keyword

Should we break the line before the + operator instead?

Should this constant name be in all uppercase?

Could the name of the boolean sound more like a boolean? eg, isComplete

Perhaps each statement in the javadoc comment could be a complete sentence? I noticed this was in other files too.

Im not sure if the first sentence should start with a verb. Perhaps "Creates..." or "Initializes..." might be more intuitive?

Not sure I can agree on this abstraction. Wouldn't this make it harder to locate the cause of exceptions?

I am thinking that perhaps this may be abstracted out because the same segment is used for events as well.

Perhaps avoiding abbreviations can make code cleaner

Maybe the pattern can be extracted for it's used multiple times

Maybe this class name can be made more descriptive?

Perhaps getting the string representation in file can be extracted to a separate method

Unfortunately I am not sure what the leading part means

Perhaps use camelCase for this variable name?

Not sure I can agree on this abstraction. Wouldn't this make it more difficult to locate the cause of exceptions?

Consider adding break; statements after these cases as well; if fall through behaviour is deliberate, consider adding a //Fallthrough comment at the end of the case block.

(The same applies for all the other switch statements in your code)

Something to consider: a reader won't know the reasoning/context behind this number

"do by" is a verb; consider changing this to doByDate?

This is a small thing, but you can also do System.out.printf( with the same arguments and add \n at the end

Consider extracting the ternary expression to improve readability?

Consider breaking before the + operator instead as mentioned in the style guide

Nice, this method of formatting is very readable!

Consider adding blank lines in these blocks to improve readability (in the other Command files as well)

Should there be a newline after the description?

Should there be a description to say when the exception would be thrown?

Should there be a full stop after the description

Should this line be one more indented by one more space? Perhaps we can align the second "" of the "/**" line with the "" of the subsequent lines

Perhaps a more intuitive class name would be FIleReader?

Would it be better to avoid deep nesting of 3 levels?

Perhaps in might be more intuitive to use enumerations for the different cases?

Perhaps a more intuitive variable name would be currentTask?

Maybe using Executes instead of Execute will better follow the coding standard?

Maybe using Deletes instead of Delete will better follow the coding standard?

Maybe using Marks instead of Mark will be better in following the documentation practices. This is repeated in other comments as well.

Should the file path be declared as a constant before passing it into the Duke constructor?

Would a more descriptive method name be more suitable here?

Would a more descriptive method name be more suitable here? Perhaps writeFile?

Perhaps starting the method with a verb? An example can be getDesc.

Perhaps starting the method with a verb? An example can be getDeadline.

Do you think these conditions' structure can be made more readable?

Perhaps an interface is better suited to describe the Command class as it does not have any attributes and it is never instantiated.

Are all these classes who extend Exception necessary? Since their messages are handled by the other class, perhaps a general exception class is better suited.

Coding standard asked for a space after for. So I think it should be: for (Task task: taskList) {

what does i represent? Can its naming be more specific?

Is the name "by" descriptive enough? Would this confuse the reader?

Is the name "at" descriptive enough?

Would recommend using back ArrayList method names since both class have similar functionalities and other readers might be more familiar to ArrayList method names. This would increase readability

Good JavaDoc

It seems you are using different classes for UI output, it's okay.

You can also do this in one single class lah

Oh you use abstract class, that's good.

Maybe name this function as executeOrder/executeCommand would be better

Good JavaDoc

Haha you made a logo for Duke, interesting!

you can just use /* */ for one line JavaDoc

Good, using different packages for different usage of classes

Maybe there are other possible exceptions?

Maybe there is string index out of range exception also?

You can add a header Java Doc here.

Personally, I would like to handle exceptions in else branch.

Maybe can use StringBuilder to replace +

If I remember correctly, we need to do at least half of Javadoc for all these files. Maybe you can do that later

Why here is an empty line

Good to create child classes to handle different exceptions

Perhaps can just use destination as the variable name since it is not too long?

Maybe try to keep the formatting coherent, in this case a new line after the else statement.

Perhaps we can move these classes out of the Duke class for better organisation.

Maybe can look into abstracting out the main logic of Duke into another class to add a layer of abstraction.

Spacing seems to be inconsistent.

Might toBeReturned be uninitialised, thereby returning null?

Should the method name be returnSearchedTasks?

Maybe the use of a new line character at the end of every statement can reduce the amount of repeated code?

Should these exception classes be moved into separate files for better abstraction?

Should these constants be named in uppercase and separated with underscores between words?

It would be good to make this portion of code more readable! For example, maybe you can consider using switch statements in place of the if-else statements, and consider abstracting the relevant logic into separate methods?

I like this quirky error message

Very minor comment, but should there be a space between the word DukeException and the bracket beside it?

Should there be breaks for each case? Or, if break statements were left out intentionally, should there be explicit //Fallthrough comments?

Should the TypeOfCommand parameter be named in camelCase (i.e. typeOfCommand) instead?

Should this boolean be named to sound more like a boolean instead (e.g. isCompleted)?

Perhaps consider not using wildcard imports?

Should case clauses be indented?

Should this comment start with "Creates" or "Create"? I noticed this issue in several other places too.

Perhaps consider using isClosed instead of Closed? This will make it sound more like a boolean.

Perhaps consider splitting this method into several methods and using switch-case statements? This could reduce the length and nesting of the method.

Perhaps consider using a clearer variable name such as deadlineDate?

This method name sounds like a noun. Perhaps change it to something like formatForSaving?

Could consider using String.format instead of string concatenation for better readability.

Perhaps this can be edited as the filepath could change!

I like how you load and parse the data!

Another possible way to do this it to define a DateTimeFormatter pattern and directly parse with that pattern.

Since this is done for any task that is timed, perhaps this can be abstracted out into a parent class?

Perhaps put a space after Task to comply with coding standards?

Perhaps put a space between the '+' to comply with coding standards?

Perhaps you can change the description for the return statement, as it does not give any additional information not present in your description!

Perhaps all of this can be handled by the parser as well, as these are all commands?

Could leave a blank line here to follow coding standard.

Try not to use wildcards and instead state all explicit imports.

The plus sign should be at the start of the next line to follow coding standard.

Can perhaps add java docs for the override methods here.

Perhaps you can add java docs for this method?

Maybe can add java docs for this method as well.

Good job following the module's coding style of indentation for the switch case!

Perhaps a bit lengthy code here? Not sure if some parts could be abstracted out of the execute method......

Should the code commented be deleted?

Coding standards state that all comments must be in english. Perhaps the previous code can be accessed by looking through the change history rather than comments.

Should the class have a Javadoc comment as well? I noticed your classes seem to be missing comments for the class.

Should your other classes be in the same package? I noticed only this file has the package line.

Should we delete this comment? This is a very large code comment. Perhaps we can reference this in the code diffs instead of leaving it as part of the code base?

Should we spill this line over to the next? It seem a little too long.

Should we replace this with the specific import instead of the wildcard?

Would you consider using a switch case here too?

Should handle be further split up into separate methods? I believe the handle method was created to help shorten the parse method, however that resulted in handle being a long method.

Perhaps a more intuitive variable name here? Maybe it can be changed to a name like storeLists because the data type is an arrayList.

I think maybe this line can be split into two lines because it is a bit too long.

I think logic units within a block can be separated by a blank line to improve readability.

I like how straightforward the logic of this code is.

I like how you changed the variable name to be more intuitive.

I like how you inserted the blank line to different units within a block.

Maybe certain parts of the class can be extracted out because it is a bit too long.

Maybe certain parts of this code can also be extracted out to improve readability?

I like how you catch the exceptions when parsing the string!

Nice to follow the coding standard!

I think there are other actions as well. Is it better to involve LIST EXIT FIND into the ActionType?

I think it's better to end the description with a '.' and the same for the descriptions of parameters. I noticed the same issue in several other places too.

I think it's better to use a split() function to deal with the input since in this case, you cannot handle the situation when the user types in a message with a lot of white spaces.

I think it is better to separate line 24 into two lines.

I think the define statements do not follow the coding standard.

I think the name of the constant should be in capital form. I noticed the same issue in several other places too.

Should there be indentations for case clauses?

Perhaps you can standardize whether to break before an operator or after an operator?

Should the setter method for isComplete follow the form of void setComplete(boolean isComplete);?

I am with @raythx98 on this, perhaps you can make use of your Parser and Storage class?

The method name isEmpty can possibly come off as vague, perhaps the method can be named hasEmptyDetails to reflect that it is determining if the detail in the input is empty.

Would it be better if your print statements were moved to the Ui class? It seems that both the methods found in TaskList and the methods found in Ui print directly to the user.

Variable name duration might come off as misleading. I would think that duration implies how long the Event would last rather than when the Event is.

The nested logic for parse seems a bit complex... perhaps you might want to abstract it further?

Can consider changing to private and using getter to access.

Can consider splitting into declaration then .run().

Can consider making private, accessed with getter.

Better name to name the scanner?

Can just return loadedTasks?

Comment should not state the obvious

Comment is missing the empty line between description and parameter.

@return type might be good to start with String representation of the deadline. Capitalize the data type for more clarity.

Will it be better if this method is documented by javadocs?

i agree that it will be better to split the various classes into different files

Not sure if Javadocs is needed since the code is provided.

Is this a placeholder for now?

Might be better if function is renamed to finding a specific thing instead of just find.

Can add an additional else statement to capture everything else. For easier debugging.

Maybe can just name this method as isExit or getIsExit. Personally I feel its more clear that way 👍

Might not be necessary to indicate all the command types in javadocs.

missing a JavDoc?

'''suggestion

    boolean reachedEndOfTaskList = (num == tasks.size() - 1);

    String lineBreak = reachedEndOfTaskList ? "" : "\n  ";

'''

'''suggestion

    return this.taskType + " | " 

            + (this.isDone ? "1" : "0") + " | " + this.description;

'''

sry.. Break b4 operator?

'''suggestion

    } else if (arr[0].equals("E")) {

        task = new Event(arr[2], arr[3]);

    } else {

        throw new DukeException("Save file is corrupt ┐('～';)┌")   

    }

'''

maybe include default else branch?

I like that 'todos' does indicate multiple todo tasks by using plural form.

I think it could it be a bit better to use more distinctive names between todo and todos? But not really needed though.🦖

Put TaskList and Task together? 🌮

To make it clearer that it is intentionally left blank rather than accidentally?

'''suggestion

// proceed to do nothing

'''

Although I admit the name DoNothingCommand does already make it obvious.

I don't like that there are some catch blocks are followed by a blank line while others do not.

Better if all were consistent?

Small typo error here. I think you meant "done" instead of "donw".

Correct me if I am wrong but I think "Arges" is a typo.

I think the parameter can be taskList (in camelcase).

I think the parameter can be renamed to taskList (in camelcase).

This could have been named HORIZONTAL_LINE as a constant, which will give the reader a better idea on what it is.

Boolean variable can be renamed to something like "isFound" or "doesExist".

I think this variable can be named as "description" to give the reader a better idea.

Task object could be named as deadLine here instead of dl.

Maybe there is no need to state that it is an overridden method.

Be wary when a method is longer than the computer screen, and take corrective action when it goes beyond 30 LOC (lines of code). The bigger the haystack, the harder it is to find a needle. - https://nus-cs2103-ay2021s1.github.io/website/se-book-adapted/chapters/codeQuality.html

Method names should contain verbs, seems like some other methods have this issue too

I believe operators(e.g. =) should be surrounded by 1 space? Seems like this happens at other places too. Could be because I am referring to Java's coding standard. Not sure if Kotlin follows that too.

Packages imported should group in a better way.

Some spacing issues here

oh oops I think I got confused between the java and ikura packages, ignore this please.

Alright then all is good!

The Java coding standard does not seem to specify if "this" is recommended or not recommended so both is probably good. Personally, I also prefer to use "this" in my constructors because I like to know what fields I'm setting!

Would renaming the field by to deadline make this field more easily understood?

I think it is good naming of the boolean variable as isDone with the emphasis instead of done!

I think the Java coding standard specifies a break between the method description and start of @param.

This may just be the formatting being off on my screen, but there may be a newline between the arguments to the Event constructor. If all appears right on your screen, my apologies!

Is there a reason the program checks if the file exists when an exception is thrown?

I like your use of enums to simplify your program and communicate your ideas more clearly!

Instead of spaces maybe we can use \t?

Should this be camel case? (e.g. listOfContents)

Should this be camel case? (e.g. numOfTasks)

Should this be camel case?

Is it necessary to have a description for constructor?

Is there any reason for the empty lines?

The commented out code could maybe be placed under the code that is still relevant or be removed?

Maybe naming the method with a verb will be more descriptive

Is there a way to give the method a more descriptive name?

From the websites it says that : "Plural form should be used on names representing a collection of objects."

So I think perhaps it should be taskLists instead of taskList.

the websites says: "Class variables should never be declared public"

So, perhaps it should not public.

the websites says: "Class variables should never be declared public"

So, perhaps it should not public.

the websites says: "Class variables should never be declared public"

So, perhaps it should not public.

the websites says: "Class variables should never be declared public"

So, perhaps it should not public.

the websites says: "Class variables should never be declared public"

So, perhaps it should not public.

The textbook says: "Distinguish clearly between single-valued and multivalued variables."

Here I assume the taskList should be many tasks inside the list?

So perhaps it should be taskLists instead of taskList

The book says: "A name is not just for differentiation; it should explain the named entity to the reader accurately and at a sufficient level of detail."

perhaps you can change the "name" variable to a more meaning name, such as taskName.

I think you are missing a javadocs header here

This method is a little too long. Maybe you would like to abstract some of it out?

Maybe you would like to remove these commented out lines?

Maybe all warnings shouldn't be suppressed?

I like how every message is in a constant.

This public class is missing a header comment for javadocs

Might be better to give a plural name for arrays

Maybe these names could be changed to something clearer like doneNum?

Should there be an empty line between description and parameter section?

Perhaps you can list the imported classes explicitly here?

Should this be named isDone instead?

Perhaps you can remove the indentation for case clauses?

Perhaps you can consider having this as a protected variable in the Task class?

This way, you won't be repeating yourself. Also, if you have more task types in the future, you will have to keep making copies of this file. Changes to the format style can also be made in one place instead of multiple.

Perhaps you can abstract the process of making a storage string?

By this, I mean that you can have a method in your ToDo, Event and Deadline classes to generate the string that is going to be saved to storage.

I believe that this might make your code more readable.

Can this line throw an exception? If so, does it need to be handled?

Can I check why this method is needed?

Can't the static print method just be called directly?

I think no indentation is needed for the "cases" after a switch clause.

I think the current design is nice and very easy to read because you make sure of enum, etc. Another alternative approach I can think of is to make use of polymorphism.For example, you can declare Command as an abstract parent class and let its subclasses override a common execute method. I believe this should shorten your code in your main class.

I like it that you ident and organize your code neatly which makes it easy to read (no diamond shape if-else clauses).

i think it is not encouraged to put dummy value like empty string as a return value cuz it might cause confusion. Maybe we can declare Task as an abstract class because there is no need to instantiate Task instance. So, in this case, we can make storageForm abstract and force the subclasses to override this method to carry out the specified behavior.

I believe that your code has taken care of the situation where the description of the task is a short phrase such as "finish this" indicated in your example, but maybe you can consider using things like | to separate components as demo by the website rather than using a white space. I personally think that will be clearer.

I like that you add a little comment besides code that might need extra work in the future. But should the comment be placed on top of the code instead of the right side?

I like your approach that declares keywords as constants upfront.

I like your use of Optional and Lambda here. I also like the way you specify a DateParser that is responsible for converting String to a LocalDate.

Maybe it should start with a verb?

findResult sounds a bit like verb I think. Probably we change to another name such as taskListResult?

Should we group it into javafx.scene statements above as well? 🤔

'result' is quite a general name and does not show it's a list of tasks. Maybe we can consider changing it to tasksResult?

Will it be clearer if we rename it to something like isValidCommand()? 🤔

Will it be better if we change class name "AddTodoCommand" which sounds like a verb to TodoCommand?

You can consider naming it as "parseCommand" instead of "parseAdd" to make it a bit clearer? 🤔

The idea of overriding equals method is great! 👍

Just a small thing, I think we should change it to "printExitMessage"?

According to the module coding standard, static import statement should be placed above other import statements, and the non-static import statements should be placed in a single blocks (no blank lines separator)

Could perhaps rename ls to taskList to make it clearer

variable name index is quite unclear, perhaps could change to numberOfTasks

Could split the print statement into few lines (this line is more than 120 characters)

All the + sign should be at the beginning of the next line.

Could perhaps consider using Enums for the type of commands

The function name printNewTask() seems like a void function. Since it returns the string representation of the new task, maybe can consider newTaskToString(). Same comment with other similar functions in this file.

Static import statement should be placed above other import statements

Maybe it is better to name the object with another better name that describes the object better?

Perhaps it is better to set isExit as a boolean attribute?

I think it will be better to indent four spaces before the '+' as this is break of a statement.

Maybe it is better to name the method as decideDeleteIndex as the index is the most concerned word.

I personally think it is better to add a blank line after this import statement.

I would prefer having a blank line after the attributes.

I think placing the '+' in front of every line is better.

It would be better to leave a line after the description.

I notice you are trying to mark a task as done. Would it be better if you rename your method to verb? For example, markTaskDone.

Is there any spacing errors?

Is it better to understand a variable or method if you use noun for variable/class and verb for methods/functions?

🤔

I am glad that all of your code is maintained below the line length limit which is below 120 char, so the code view is better. 👍

Would the readability improve if you break the line before operator? 🤔

Would the code more readable if you use extra method to handle the conditions? 🤔

I notice this method code is very long. Will it be look nicer if you handle each condition by using another method instead of putting all of them in one method? 🤔

I like how you handle all Ui messages for user in Ui class 👍

I like this! Follows the coding style guide almost to the tee 😄

Not to be pedantic, but to keep in line with the coding standard, should there be a new line at the end? I've seen similar things in other files as well.

Any reason why the class and constructor do not have javadocs? I noticed the same thing in other files too.

Not sure I like the absence of javadocs here

Should the indentation be 4 spaces instead?

Any reason why "magic numbers" were chosen over literals?

I feel this method is too long, and too difficult for a reader to follow

Should the variable names be more expressive here?

I didn't know you can do this! Nice 👍

just a small suggestion, maybe you can mention that input.split(...)[0] is the firstWord of the input by creating a variable so it's slightly clearer!

I think you can add in brackets based on the coding standards, but your code is really neat!

Just a small suggestion, perhaps you can consider using a single letter 'e' to represent the exception but taking the first letter of every word is an interesting way to do it as well!

I like your comprehensive checks!

Nice use of switch cases! It'll be good if u add a oneliner comment to briefly describe what rm is 😃

One small suggestion: I think you can remove the comment since you've already mentioned what this function returns in Javadocs.

One suggestion (after looking at AB2's code) would be to make this into a method though the current one is fine as well!

eg. UserInterface.showGreetingMessage();

I may be mistaken, but i think the split() method does this.

I've noticed this is your only Exception class. I feel it would be more apt to have multiple Exception classes that extend from your DukeException, each with their own message. For example, InsufficientArgumentsException extends DukeException.

Im confused about this part. You are throwing it, to catch it to throw it again without change? unless the constructors throw a different kind of Exception?

Maybe the welcome message can be handled by the Ui?

I'm confused about the need for this exception class. Why not just throw an Exception if there is no overriding error message

In relation to my comment about this exception class. Maybe overriding the toString method of this class to print the error message would be better? I understand you need the args1[0] variable also, maybe you can pass it along as an argument in the constructor of the exception?

I may be mistaken, but if you're going to repeatedly try-catch the same exception, maybe wrap the entire if-else statement into a try-catch block?

Good abstraction. Code is clean and it is obvious what class handles what.

A switch-case could make the code more elegant here 😃

Shouldn't there be a "throws DukeException" here?

Should add a "throws DukeException" here as well! Unless i'm mistaken

Agreed ^

This usage of if - else works for sure, but perhaps the use of switch - cases would be more appropriate in this case.

Minor issue tho xD

Great use of enhanced for-loop and enum to allow for multiple date formats input by the user 👍

Did not think of this at all 😃

^ I disagree, I think all the needed abstraction is already done. I might be wrong tho

This access modifier can be set to private, since there's a setter method and a getter method for the correct symbols already implemented.

Perhaps it might be better to check if taskList.isEmpty() at the start so as to avoid deep nesting? Or maybe it would be good to create a method that checks if the taskList is empty so as to avoid code duplication.

Maybe it might be better to explicitly list the files you are importing instead of importing all the files?

perhaps it would be good to have an empty line between the descriptions and parameters.

Also, perhaps it would be great to split up this long method to shorter ones?

Using isExit for the boolean looks great. Perhaps shouldExit would be a better name for this method?

perhaps FORMATTER would be a better name for constants?

Perhaps ERRORMESSAGE would be a better name?

this variable name is clear and sounds like a boolean. Great naming

Is the period supposed to be there?

Is there a missing punctuation mark for the error message?

I don't think this is grammatically correct. However, the more crucial point is regarding the method name: What is the subject being referred to here, i.e. create if what does not exist? (to consider renaming)

Do you mean loadSavedFile()?

I like how clean and straightforward this file is. Good job!

Does tryParseDatetime() imply that it may not be "parsable" in some cases? If yes, would you consider throwing an error? And if no, perhaps consider giving it another variable name.

I love how you aligned the params' descriptions here and elsewhere in your code. It does improve readability 💯

Huge chunk of code here but because of great coding standards, they are understandable. Good job!

You may want to change these comments to single line Javadoc comments e.g. /** Scanner to read input */.

This would also apply to any class members in other classes 😅 . (You can look for the example "Javadoc of class members can be specified on a single line as follows" in the conventions page! 😄 )

Maybe you could add a period (".") after all sentences in longer Javadoc comments? So that punctuation is consistent and the generated Javadocs would look more complete/professional. ^^ (To be clear, this refers to other Javadoc comments as well~)

Maybe you could capitalise the parameter descriptions and punctuate them? Since the conventions page states that we should have "Punctuation behind each parameter description". You could also refer to the given example as reference 👍 .

Should "Write" be written as "Writes" instead?

Should there be an empty line between the description and the parameter section? This styling seems to only be in certain classes and not others.

Should there by an empty line between the description and parameter section? This also refers to other Javadoc comments 😅 .

Would this look clearer if the break occurred before DateTimeFormatter?

Would displayDeleted or displayDeletedTask be a clearer method name?

I think you could use a clearer name for boolean so that we know it is a boolean value such as isDelete or shouldDelete:)

It would be better to name the variable "tasks" in this case as we would want to differentiate between single and multi-valued variable!!

I agree, using StringBuilder with append() method would improve the runtime of your code!!😃

I like the way you used %s %c for your string representations, ive never thought of doing this before!! It looks great:)

I think the recommended JavaDoc for methods with parameters is that you describe the parameter in a one-liner, so maybe "@param command command of user" would be better!

As above, here you could include the description of your parameter

I think according to coding standards they recommended that we put plural form for collections such as lists, so here maybe 'tasks' would be a better variable name!

I think according to coding standards it should be currName and not currname!

Perhaps add a description to the parameter name in the Javadoc comments to make it clearer?

Perhaps add a description for the return value for Javadoc comments to make it more complete? I noticed this issue in several other places as well.

I like the way the if-else conditions are constructed. They are really clear!😃 👍

Should this part be extracted out? Perhaps consider creating multiple command class to handle different commands in order to improve the readability of following command method? 😃

Perhaps use verbs for this and the following methods' names?

I like how you write the Javadoc comments. They are really clean and clear! 👍

Perhaps it would be better if the space between the parameter name and description is consistent?

Perhaps it would be clearer if the comment contains a phrase rather than a word(e.g // Handle Todo)?

Could separate logical units within a block by a blank line

Great idea to use HashMap to store commands

Could perhaps add a more descriptive sentence eg. "An error was thrown: " since the user will be seeing the error

Can add Javadoc description for more functions

Can try to split imports based on which package they are from for better readability

Good idea to use final variables for the error messages

Perhaps this switch can be implemented as a different function?

Could split into logical blocks for the try block

Perhaps it could be indented 8 spaces more than the parent line?

Maybe an empty line between description and param section?

Perhaps punctuation behind each parameter description could make it look neater

Since this attribute is initialised for each new Ui, would it be interpreted as a constant? If it is not a constant, could the naming be improved?

Apologies, on further thought I think the indentation adheres to the coding standards.

I believe there is no clear guideline on this, but generally if that attribute is going to be the same for all Ui objects, my personal preference would be to initialize it when it is declared.

Maybe it could be named as an action?

Maybe could specify what you are loading?

I like how you used a switch statement to check for the different commands.

I like how you abstracted away the commands into a command class

I like how you used an enum class to declare the commands

I like how you abstracted the output into different functions

I like how you used a switch statement to check for the type of command

I like how you used an enum class for the different commands

Perhaps the variable name can just be pos?

The empty spaces might not be required?

Really good Parser class, abstracts all unnecessary work to other classes

Really nice Task classes as well.

Styling error, no need for the this keyword.

'''suggestion

    return usage;

'''

Additionally, I think perhaps you should shift away from the enum methodology of splitting commands as you lose alot of the functionality of having separate classes for each command. However, for the moment it seems to work well so this is only for projects where the functionality of each command is large.

By using a Class based system for the commands rather than enums, the parser can be simplified greatly by abstracting all the exception handling as well as all the UI based responses. As the project grows it will allow the project to scale better, especially if commands have new functionalities added which is often the case with breadth first iterative approaches

The this keyword is not necessary and based on the style guide should just be,

'''suggestion

        File file = new File(filePath);

'''

The variable names are a little hard to understand when scanning through the code, try to just use date and time

Do you think you can abstract all the printing statements and errors for all your commands to your UI class since its purpose is to manage the user interface including all the error messages and command responses?

Add a " " after each ",". I noticed the same spacing problem for other areas.

Perhaps you mean stringToBoolean?

Can be more clear on method name perhaps? Like parseCommandInput for example.

More ideal perhaps to close scanner after use.

May be more efficient speed wise to concat every line and make it into a constant variable.

Change the method to abstract if you intent for the child classes to set their own logic.

Constant need to be full CAPS

Maybe you could consider creating a UI class that is in change of outputting messages to the user?

Maybe not a good idea to use "listOfStuff" as a name since it's too generic, perhaps can use "tasks" instead?

Take note of the whitespace that needs to be added after and before "{", "}"

In the future, I think it will be a good idea to refactor the code here into several classes (i.e. storage, ui, etc) for better readability and organisation

Since taskList is a collection, would it be a good idea to use a plural name like tasks instead?

Perhaps can change the function name to include a verb e.g. getScenarios?

Nice use of switch statement, really easy to read the code. 👍

Is there a reason why these fields cannot be private?

Some of these fields can be final.

Is there a reason why the naming for the String[] title is different from the equivalent in the other methods

It may seem like there is a lot of duplicate code among the methods below. Perhaps some of it can be extracted out.

Could there be a better naming for the array?

Perhaps verbs can be used to name the methods instead.

Perhaps these Strings can be saved as constants instead.

Perhaps it would be better to initialize these members in a constructor?

Maybe getTimeMarker should return an Optional, so that you do not deal with null from Todo's getTimeMarker(). I think it's a better practice to avoid null values. Or perhaps shift the time-related members to Event and Deadline.

The code here is very readable, good!

I like how you extended from DukeException to create more specific exceptions for different cases!

Perhaps you should set the access modifier to private instead of protected. Same for the Event Class.

Consider a more meaningful name like "formatter"

I feel that f and sc could be renamed to more meaningful names as well rather than their abbreviations.

Maybe you should delete these? It doesn't seem like you need them anymore

Maybe you should delete these too? If you want to keep old code maybe you can put them in a separate file as a backup instead?

Perhaps you can throw the exceptions here rather than do it in Duke.java? It seems a bit strange OOP wise to have a command called "EMPTY_TASK_TODO". I think you can skip that and throw an exception immediately.

Consider removing these commented lines if you no longer need them?

Consider changing "commandArr" to "commands"? Coding standards say collections should be in plural form.

Since you're already using "this" keyword, I think the param "done" can be changed to "isDone"?

Maybe this should be a boolean attribute "isExitCommand" accessed by "isExitCommand" getter? I think "isExit" is a little unintuitive.

There's no indention for the case statements. It should be 'aligned' with the switch statement.

Maybe you could abstract out this border line as a variable, then call it whenever you need it. Makes the code tidy.

Perhaps you could add appropriate line breaks to enhance readability

Same comment as above. Line breaks for readability.

Maybe you could rename 'noArgs' to 'hasNoArguments' or 'hasArguments' >--[you might have to rewrite some code if you change to this 😦]

Perhaps you could change 'found' to 'foundTasks' etc? Plural form should be used to represent a collection of objects 😃

Maybe you could rename 'taskDoneState' to 'isTaskDone'?

Perhaps you can be more specific on what things are on the list?

Maybe the class names can sound better if they are singular instead of plural?

Perhaps this can be named to sound like a boolean?

Should the getListView() method be more clear on what it does?

Perhaps the line can be broken before the operator '+' ?

Maybe you can include javadocs for this command too?

Perhaps this method can be more specific in what it does?

Maybe capitalize the first letter and separate the description and parameter?

Maybe reduce some redundant empty line for better readability?

Small typo here.

Maybe separate the method and javadoc? I know this is a check style issue, but I still feel that separate them makes more sense, so I suppress the warning. If I'm wrong, just correct me. Thanks.

Maybe add comment and separate logical block? Eg. Add // Parse command here

Maybe the line should belong to UI?

Maybe here should indent the line?

Should the naming of the ArrayList be more explicit? i.e Tasks or taskList

Should the method name be in plural form? i.e getNumOfTasks()

Should the method name be revised to include a verb? i.e printWelcomeMsg()

Should the method name be revised to include a verb? i.e getSize()

Should the param for this method be more explicit? i.e String msg

Should there be a Javadoc describing the class?

Should this be explicitly named tasksContainingKeywords instead?

This method might be a little long?

loop as a method name, could it be a little vague?

I think class names should be singular?

Method name might be a little vague? Since the method returns a list.

Perhaps method names can be verbs or actions?

I think public methods should have comments?

I think if else statements should have curly brace?

Might want to leave an empty line here for better clarity.

Would it be better to capitalise logo as it is a constant?

Would suggest renaming to FILEPATH.

Possible to make Event extends Deadline? Might be more coherent

Generally I feel that addDeadline/addEvent can be compressed into a single method addTask as Event/Deadline extends Tasks so it will work.

Maybe leave a line here for better clarity?

Leave a line here for better clarity.

Perhaps can consider using a verb for the method name? (E.g. CombineAllTasks etc)

Bye might be a little confusing haha. Consider including the fact that it writes data.

Great to see that you've updated your README. Do consider adding links to the tutorials you've used for certain code. (E.g. JavaFX)

Good to see your indent for switch statements as well as adding a default case!

Great extensive testing used for each command.

I think there seems to be extra white-space here.

Just a small reminder to leave a line after the header for Javadoc to follow the coding standard!

Will it be better to list out all the classes in the package following the coding standards?

Maybe it will be better to put inbuilt java classes on top of custom packages to follow the coding standards

Would a more descriptive method name be better?

Maybe using Initialises instead of Initialise will be better to follow the documentation practices

Will it be better to keep the indents to the same level for neatness?

Perhaps it will be better to remove all these white space to improve readability

Might want to consider a better name eg. createToDo etc..

Maybe you could refactor exception checks to another function

Maybe a better naming convention like findMatching?

Javadocs for this function could be changed

Maybe a javadocs here to indicate that this for exiting the application

Should there be a header comment since the accessibility is public? (line 58)

"task" should be private and accessed with getters

It seems like it should be "tasks" instead of "tasksList" and i believe you should use a getter method to get the description instead.

switch case should not have an indentation as per the coding standards

Perhaps you can add a validation check to check if the input is completely empty.

I believe that your storage class should contain a reference to the task list.

I am not sure if LinkedList is the best implementation for tasklist. I think that ArrayList is better as there are alot of index calls which would run in O(1) time.

I agree with the above comment that ideally you should name out the exceptions and handle each exception seperately.

The case indentation should be the same as switch as per the coding standards.

I think it is better to merge the 2 switch cases. Furthermore, your switch cases here should have a default case.

This could be handled by a Parser class

Shouldnt different classes be put into different files ?

I think this function name should be more expressive

You might want to use the low dash to separate words in this enum value.

This chunk of code can be truncated by using a parent class of all exceptions.

The Command class should only handle common operations among commands, specific operations like matching can be put inside subclasses.

Testing addTask() and deleteTask() with the length of taskList might not be enough. You may want to check the newly added/deleted task also.

You might want to put punctuation here. According to the coding standard, the first line should be a sentence, and every parameter description (@param in this case) should be punctuated with a full stop.

Instead of wildcard imports, you may want to show every duke class you imported. Perhaps you may want to check your IDE settings if need be, sometimes they automatically condense all your imports from the same package if they hit a certain minimum requirement.

Normally we use this grammatical mood (e.g. starting with "Implements") to describe our Java methods, but for classes you may want your header comment to focus on what it is, rather than what it does. For this example perhaps we could call it "Implementation of a Duke called Wyre." and then apply it to all the other classes. For example, you could refer to the JavaDoc headers for MainController and DialogBox.

Aside the previous comment where I suggested adding punctuation, you might also wish to consider putting a blank line between the description and the parameters.

Is there a reason for having keepApplicationRunning? Perhaps you could consider simply using sc.hasNext() instead. On that note, you might want to rename it to isRunning as in accordance with the coding standard.

"bye" could technically be treated as a command. Having the "bye" command case here instead of in line 42 might cause both an inconsistency in abstraction levels and deep nesting. Perhaps you could change the Parser.parseCommands() method to also factor in the "bye" case, in which it would call sc.close()?

This would also set sc.hasNext() to false, which naturally breaks the loop and ties in with the earlier comment.

This is pretty deep nesting, perhaps you might want to split this off into its own private method?

Maybe you could elaborate a little more on the ui parameter? It appears to be abit unclear about how the ui will reply the user.

For the separation, you could put inplace dividers as comments to 'prettier' your code. Maybe like a form of comments with format. I have found it helpful when I pick up anothers' person script to work on when they have extremely beautiful comments to make the code readable. I find that extremely easy to read as compared to just if and elses.

Perhaps you could try adding a more elaborate description of each instruction for future reference?

Nit: not much but I think the linebreak here is unintentional?

This could be a typo that may throw gradle errors

Perhaps you could add some elaborate documentation for each instruction for future reference?

I think this linebreak could be removed to make the code more succinct?

Perhaps may be better to change the name of the method to be of more explicit verb form? 😃

Hey I like the structure of your code here 👍 clean and easy to understand 😃

Hey maybe it should be i++ for the for loop increment? - Not sure if this is against the coding rule, but according to the coding rule page, i++ seems to be the recommended form 😃

The coding rules were generally well-followed! The variable names and method names were clear/ easy to understand as well 😃

Hey I like the structure/ design of the code for Parser!

Perhaps, would it be better to create separate class for each error ("Oops" statement) that inherits from this DukeException class? Such that it displays the error message instead in the handleUserInput() method. - Just a suggestion! But it still looks good 👍

I meant this kind of error statement in the first comment!

Maybe you can have a new empty line indentation after your package line before your import statements?

I like how you return your output as an ArrayList to be processed later instead of immediately returning a processed string since this could improve adaptability and extensibility of your program! 👍

Perhaps it would be more readable if you had the for-loop in the form of:

for (int i = 1; i < foundTasks.size() + 1; i++) ?

If you are using IDEs such as IntelliJ, perhaps you can consider setting your preferences to not auto-optimise the import statements to avoid the IDE from replacing you import statements which seems to show you were previously aware not to use the wildcard import statement! 😃

Is there a particular reason you decided to convert ArrayList to Task[] before returning?

I like how you have a string output to indicate that no tasks were found 😃

Perhaps you can add fullstops at the end of your method descriptions?

Breaks should be done after the + operator here.

You might have accidentally missed out the javadoc for this public method.

Small issue here - the spaces should be avoided.

There should be an empty line after the description of javadoc comments. Noticed a couple of this.

You might have missed out this javadoc for the return statement.

You might have missed out some javadoc comments in this java file.

Missing some javadoc comments here in the public methods.

The "done" case should end with a break; statement. You might have unintentionally shifted the "done" case into the "delete" case.

A break statement should be included for the default case too.

Should it be "Creates a Deadline object" instead?

I think that the {@inheritDoc} might be helpful here if the JavaDoc of the overridden method is the same.

Should there be whitespace before the curly braces?

Perhaps a more intuitive variable name here? For example, taskDetails

Just a thought of mine but perhaps these implementations could be handled by their respective command and Ui could purely be in charge of printing out the String outputs given by the execution of the commands

Shouldn't the 'if condition' and the 'following {' be separated by a single whitespace?

Perhaps the relevant Task libraries could be listed and imported explicitly instead of using a wildcard import?

Perhaps you could add some line breaks to improve readability?

Do you think it might be a good idea to specify the data directory path inside this class as constant instead of taking it in as an argument because the data directory is fixed anyway?

Not an issue, but a question. What does Viscount stand for? 😃

This is a very nice use of stream here. Keep up the good work 👍

I realized this part is quite different from the example. Could you briefly explain why you created a new fxmlLoader object inside the MainWindow class instead of the Main class?

Hi, is there any special meaning you choose protected here.

Hi, I am not sure whether it is unnecessary to check whether the length is equal to 2.

Hi, I think it is better to name this method as getNoOfTasks.

Hi, is there too much space here?

Hi, some minor grammar mistakes here may make the comment not readable. Perhaps you may correct it.

Perhaps you may include @return in JavaDoc.

Would it be better to name this method using a verb instead?

Would it be clearer to spell out "Number" in the method name instead?

Would it be better to list the imported classes separately?

Would it be better to include the function parameter in the JavaDoc?

Should this class be documented?

Would it be better to document this method (as well as getDukeDialog below)?

the naming of a collection should be in the plural form, in this case, tempEvents

nice try using enum!

Can this expression be shortened?

can this expression be shortened?

why should the length of dataTimeSplit be 2? maybe you can add a comment to explain it

how would it handle the case when type does not equal T, D, or E? perhaps an else block would help!

Should UI be named in caps as it does not change?

Can this be a more meaningful identifier?

You may want to indicate that it is list for inputs?

Would adding java docs be useful in clarifying where this components may be used?

Would splitting up lines in this function be better for clarifying the nests?

Is this a good way to name your method? It may be clearer to specify getTaskAtIndex instead. This is so that it would not be confused with find

There should be no indentation for case clauses.

Line 15: minor typo "taskManger"

Good job in following the coding standard for wrapped lines!

The ordering of import statements is really consistent for all the classes so far, keep up the good work!

Line 27: Minor typo "taskManger"

Good job in following the coding standard for switch statements!

Perhaps the boolean should be "isValidInput" instead to sounds like a boolean I think?

Perhaps this kind of multivalued variable can be named as "tasks" instead of "list of tasks" I thought?

Perhaps here the "lastGreeting" variable is a constant and should be named as a constant?

Perhaps the class name should be consistent with the "DeadlineTask", like "EventTask"?

I thought maybe the name of the description of tasks is a bit confused.

Perhaps the class name should be consistent with the "DeadlineTask", like "TodoTask"?

The logo can variable can be set as a private static field.

Nice work. Constant names must be all uppercase using underscore to separate words.

This method is too long. Might make it very difficult to debug 🤔

Plural form should be used on names representing a collection of objects.

Method names should be verbs

could it be written as getId(...) since acronyms should not be uppercase when used as part of name? 🤔

You could use Switch-case statements for cleaner code and perhaps you could separate certain portions of code into helper functions to increase readability.

This is implied if you do not write it as well!

Looking at this class, correct me if I'm wrong but if you would like Deadline and Event to inherit from DatedTask without DatedTask being instantiated, you could make DatedTask abstract and inherit from Task.

Maybe list instead of tasks would be clearer?

Implied if not present but nothing wrong too!

Sure that sounds good!

If I'm not wrong, the indentation for the cases is correct! I really like this use of the switch statement, and it's very readable.

final variables should declare in all caps! good use of constants though

good use of async!

can consider declaring as final

Would be nice to have one line/brief description! I know that you describe in the return what its returning, but would be useful to maybe include which represents what?

Missing javadoc, but also since minimal is only half of public methods to have javadocs all is good

Have you run checkstyle?

Perhaps can split into Parser and Command classes?

extra spacing

Good use of stream!

Good use of varags

Maybe could try out SimpleDateFormat as alternative

I think you can add a line in between the parameters and the description of the method

Hi! As this is a constant, i'm not too sure if the name should be "filename" instead of "FILE_NAME"? Although checkstyle does point it out as an error on my case but I'm not too sure.

perhaps the naming of the LocalDateTime object could be more specific?

Naming of 'at' could be more specific too in my opinion

Hi, I think the naming for the variable filepath should be filePath instead

may want to import duke.TaskList above so that you can just refer to it as TaskList, not a major thing though!😃

Hi, same thing here regarding the naming of filepath

Maybe name this to taskList instead of using tasks to avoid using plural form since there is only one taskList?

Perhaps you can add a space between imports from different packages to makes it easier to browse the list and determine the dependencies when there are many imports

maybe use the full word description instead of desc for easier understand?

Perhaps can break up this method into shorter methods?

Maybe rename reached to reached[Something] so that it will be easier to understand?

I am not sure tho but is the use of final necessary?

Maybe delete the else statement to avoid deep nesting?

Can the numTasks++ put in here instead since every if else statement has numTasks++?

Maybe use date instead of at to be more descriptive?

Should this be create method instead of setter?

Should the stringarr be in camelCase?

Can the method's name be an action?

Should there be header comments for all public classes and methods? (See Java coding standard -> Comments)

Should the comment be indented relative to the next line rather than the previous? (See Java coding standard -> Comments)

Should the wrapped line be indented 8 spaces relative to the parent line (line 20) rather than the previous line (line 21)? I've noticed the same issue in other parts of the code as well. (See Java coding standard -> Layout)

Should imports be listed explicitly? (See Java coding standard -> Statements -> Package and Import Statements)

Should constant names be all uppercase with underscore as word separators? (See Java coding standard -> Naming)

Might be a little nitpicking, but should the method name be more detailed (e.g. convertCommandToEnum)? (See Week 4 -> Topics -> W4.6d)

Perhaps it would be better to use explicit import statements. It can serve as a form of documentation regarding the dependencies a class has

Would it be better if the indentation of the case statements follow that of the coding standard?

Not sure if I like the style of the JavaDoc comments. You can consider following the style set out in the coding standard: Start off the summary immediately with a verb like "Returns, Reads, Adds... etc". Additionally, should the text in the return annotation, specifically the part on "reads the txt file", be part of the method summary instead?

Is this method too long and hard to understand? Perhaps the logic related to parsing the user input can be abstracted out into the Parser class

Perhaps you could consider leaving some blank lines in between imports from different sub-packages to improve readability! Noticed that you did so in some cases but not all. Maybe it would be better to be consistent throughout!

Could this nesting of the if statement be replaced with a && operator?

Quite an interesting way of setting up the command that I wouldn't have thought of. Is there a reason why you did it this way instead of putting them all in the constructor?

Minor nitpick, but you could have just use "\n" to continue printing on the next line instead of calling println twice

I like how there are comments in the middle of the code to explain why it's done that way. Makes it easier to understand while reviewing 👍

Minor nitpick, but I believe this string can be set to private as it is only called within Duke. But it doesn't really affect the code and is more about code presentation

Is there a reason why this boolean check is repeated twice?

Hey, minor nitpick, but I believe that according to the coding standard, imports should all be listed explicitly. I noticed the same issue in the other classes as well

Perhaps the method name could have been a verb instead? Eg. parseCommand.

Shouldn't there be a space between the description and param section?

Perhaps more description for your method name might be better eg. loadTasks

I think you missed out on whitespace here!

Perhaps more description might be better? Eg. loadTasks 😃

I think there should not be a space here between the method name and parameters according to the coding standard 😃

I really like how you lower the cases of the command before matching them.

Maybe leave the javadoc right above the method declaration would make it look nicer.

Perhaps a @see tag would make the documentation look a little bit more organised.

The name Option might seem to be a little bit vague, maybe a more specific name would make the code a bit easier to read.

Execute1 and execute2 can be a little bit vague, maybe a more specific name can make this part easier to understand, even the name can speak for itself. 👍

These two layers are catching different exceptions, perhaps rearrange them in a single try-catch can make it look more beautiful.

Maybe should initialize this together with commands to make the code neater?

hmm 'out' seems a little ambiguous here maybe can rename for better readability?

Just wondering, is there a reason for putting each in a new line? haha

Interesting use of abstract class, didnt think of making my Task class abstract haha

agree with the comment above, makes code a lot neater

Javadoc missing full stop

I think you could add a full stop to the end of the statements?

I think there should be a space between try and {, and in lines 139 and 143 for the for loop

i think you can remove this line

i think there should be a line between the description and the return value

Good OOP implementation here!

Code is clear and easy to read 😃

Perhaps you can standerdise the use of 'this'

Perhaps you can use String.format

Ryan Tan from 1231 says hi

Perhaps you could use String.format instead of manually concatenating the strings.

it would be good to standerdise the usage of this

perhaps you could split the appends into individual lines for better readibility

I think this.text = text is missing in the constructor code block.

I think defining the type of a generic class e.g. ArrayList<Task> here would be better.

Any reason using store instead of the plural form of task e.g. tasks ? I feel tasks would be more intuitive, just a suggestion.

i feel generally a camelCase of the class name would be more intuitive than coming up with another name for the class itself.

'''

Storage storage

TaskList taskList

Scanner scanner

'''

Perhaps the ? new Deadline(nameDateTimeStrings.get(0), taskDate) can be on a new line to maintain consistency and neatness.

perhaps totalTaskSize() would be more verbose.

I don't think there is supposed to be indentation for case clauses for switch statements so perhaps you could configure your IDE to follow the style in the Java coding standards?

I noticed that all the classes that inherited from the Command class did not include Javadocs, especially for the public methods like the execute method. Your method name is quite intuitive but perhaps you could include Javadocs for better clarity?

Line 31 seems quite long so I think it would be good if you could do some line wrapping.

I think your code looks very clean here!

Very minor style violation here, but I think there should be an empty line between the description and parameter.

Line 171 and 172 seem a bit long so perhaps you could do some line wrapping?

The purpose of the method would be clearer with javadoc comments for each method.

This line should be indented with 8 spaces.

"task" should be indented with 8 spaces.

This should be indented with 8 spaces.

This line should be indented with 8 spaces.

These two lines should be indented with 4 more spaces.

Try not to use .* imports.

Perhaps you can include a default case for switch statements.

Perhaps it should be "Shows all...". This is seen in the javadocs comments for other methods in this file and other files too.

There should be whitespace before '{'. This is seen in other block statements too.

Perhaps you can try to keep this method shorter by abstracting the code for string splitting and comparing to the Parser class.

This method does similar things to the load() method in Storage. Maybe you can extract the logic into a new method in this class and apply it in both classes so the code can be shortened.

Good job writing your code. It looks readable and clean

Perhaps you can split out the import statements for java.io.*

Perhaps you can change the name of this attribute to a proper boolean name.

As a person taking the same project, I easily got the context and logic of your code. Perhaps you can improve readability by adding more abstractions or comments to guide other users into understanding your parse method.

I think your UI is very personalised and it is very interesting that your bot revolves around this theme.

Despite the sophisticated function of this class, you have made your code readable and clean.

I think the usage of public instance variables should be avoided, especially when the constructors do not initialize them all. They could be accidentally accessed before initialization or modified by an irrelevant object.

I like how you have a String fallback for the time of a task! That gives the user more liberty when inputting time. However, I think maybe you can give more descriptive names to these two variables and leave some comments to explain your design.

I think the name "lists" is a bit misleading here, because it's a list of task rather than a list of lists. Maybe it's better to change to a name related to "tasks".

May I know why you represent all commands with one class instead of one class for one command?

I like how you abstract Command as a class. It looks nice and clear and makes adding a command easy.

I like how you covered a wide range of possible formats.

Would it make the whole project more well-organised if these extra classes are written in separated files?

Is it going to make codes more readable if you put lines below into a separate method or class?

Is there a need to declare Todo as a final class? I think there are still some possibilities to extend this class though we might not need it in our iP

Would it be simpler if you use LocalDateTime here?

Indentation for wrapped lines should be 8 spaces.

Are there any specific exceptions other than InvalidDateException that you are expecting to be thrown from the try block?

Any reason why you chose to combine the variable assignment and checking != null within the while condition, instead of keeping them separate? In my view, the second option might improve readability.

Should this member be named in a plural form (e.g. "tasks") since it represents a collection of Tasks?

I am not too sure how common a practice it is to name a Scanner object "sc", but might it be better to use a more descriptive name such as "scanner" or "scannerObject" (especially since it is not referenced until line 70)?

Is there a reason you decided to include this alternative constructor for Task and its sub-classes? In my implementation I only included a single constructor, and used the markAsDone method when needed.

As per iP task on code quality, should the JavaDoc contain descriptions on the input parameter?

As per iP task on code quality, should this function be accompanied with a JavaDoc?

Commenting on coding standard as per iP task, should there be a space after 'if', before the open parenthesis?

As per iP task on code quality, should this test be documented?

Commenting on coding standard as per iP task, should the JavaDoc for the function be specified here?

I think you can use a switch statement (and perhaps Enums as well) to make your code more elegant.

I think you should try to avoid arrowhead code over here.

I think it is a good idea to park your toDatabaseStringRepresentation method under each of the Task classes (and with Task being an abstract class that the other subtasks can inherit from) to prevent the check for instanceof's. (Let Java polymorphism do the work for you).

Shouldn't the Javadoc for this function be completed?

Good job on the regex, but I think "\\s|\\s" will be more elegant

Perhaps a more descriptive name such as "atDateTime" could be used here.

Perhaps can have isExit() to returns false in Command and only override the method in ExitCommand

Perhaps can use Enum for all the command words

Perhaps can simplify this or use another way to express it? Looks very complicated.

Perhaps the variable name could be atDateTime instead

i believe operators should be surrounded by a space character!

perhaps consider separating the java and javafx imports?

similarly, add some space characters!

Similarly, I think you can consider using dateAt instead of at so it's clearer what the variable is referring to.

I think you can consider using dateBy instead of by so it's clearer what the variable is referring to.

Consider avoiding the use of unnecessary "this." to refer to an attribute unless it is shadowed by a parameter with a similar name.

Consider following this naming convention for test methods:

"Underscores may be used in test method names using the following three part format featureUnderTest_testScenario_expectedBehavior()"

Have you considered making this method private? Seems like it is already invoked in the constructor and the client likely won't need it

Perhaps a argument name like remainderString would fit better to tell a reader immediately what the argument is

Consider only using of this. when referencing attributes that have been shadowed by method/constructor parameter names

Should this be named with anchorPane instead of ap to be consistent with the naming above and below this line.

I really like the existence of this class.

According to the module's coding standard, should the import statements be arranged in a consistent order or their dependencies? This suggestion applies to other import statements as well.

Should this Scanner be named scanner as it is in the scope of the whole class? I refer to the point below in the module's coding standard:

"Variables with a large scope should have long names, variables with a small scope can have short names. "

According to the module's coding standard, should this be named with a noun?

Should the classes in main.java be imported explicitly instead of a wildcard import?

Is giving your enum a noun name a better idea?

Maybe you could order the imports by their type? i.e. all the imports from duke.io together and duke.task together

A plural form name could be used instead for names representing a collection of objects

I like how the case statements are not indented 😃

Should there be no indentation after switch case?

Tt would be better if you could declare class variables as private or protected instead of public.

This constructor may also need a javadoc?

Since error messages follow a similar format, maybe you could have another method e.g. createErrorMessage(String) to create the string?

Should there be no indentation after switch case?

Perhaps it might be cleaner if you delete dead code instead of commenting them out? Since you could always retrieve old code from previous commits.

Perhaps it might be cleaner to abstract this while loop into a separate class/method?

Perhaps Parser could have been completed before pushing to github? If not, some reviewers might be confused at the empty class implementation.

Perhaps it is better to rename "splitTime" to "periods"? Since according to the java coding standards, collection variables should be in plural form.

Perhaps it may be more intuitive to rename the variable "terminated" to "isTerminated"?

I think in general some of your javadoc formats may be a bit off, maybe add a fullstop after the first sentence?

Maybe a javadoc for this public method?

Love your usage of enums for action type!

maybe a better function name here would be better, something like parseCommand

if possible, best to avoid arrowhead coding here

Perhaps having a more easily understandable variable name to make it sound more like a boolean?

Perhaps consider using a final int to store the value 4 as a constant with a comprehensible variable name, to avoid the use of "magic numbers".

Perhaps having a more easily understandable variable name to make it sound more like a boolean?

Consider using switch statements for better multi-way branching

Perhaps using a more intuitive variable name for tests,in the following format: featureUnderTest_testScenario_expectedBehavior()

You might have accidentally missed out the javadoc for this public method.

You might have accidentally missed out the javadoc for this public method. I noticed the same issue in several other places too.

Try not to shorten variable names so they can be more easily understood.

Perhaps name the File variable as file. 'f' should be used for scratch variables (ie. short term use).

Try to follow camelCase and avoid abbreviations for variable names

Should this method be called updateFile instead?

"update" alone may be too vague and can be confused with updating the class' state or updating individual task data

Should this method just be called "equals"?

This method already belongs to the CommandKey enum, so it would be called as CommandKey.equalsCommandKey, which might be redundant.

Just having "equals" would also match the equals method for other data types like Strings

Would it be better to name these as "LINE_XXX_XXX" instead?

Should these variables be final?

They appear to be constants and prefixing them with the same word will make them appear together when sorted alphabetically (see coding standard document)

Should there be JavaDoc comments for this method?

Should this method be named getTasks_normalFile_getCorrectly instead?

statics should be in CAPS

as above

'''suggestion

                                taskData.getDateTime(), Parser.TASK_DATA_DATE_TIME_FORMATTER);

'''

Not sure whether you really need a getter when you can make the isDone boolean public

Perhaps you can move the description to the class file itself? To reduce clutter

Maybe instead of declaring isExit, how about while(True)... and break/return when condition is reached?

Maybe it's more readable to put it in a single line instead

Not sure whether you really need this, Java has default constructors

Maybe a more representative name could be used to represent the splited string Array? eg splitStringParts

Perhaps a more specific name such as startDate instead?

Maybe a comment should be used to explain what n represents, and why 2 is used (magic number)

Your variable name used to refer to the TaskList varies by using list here and taskList in other places, would it be better to use one name throughout to maintain consistency and reduce confusion? e.g. using name taskList throughout to refer to the variable TaskList

Perhaps a more descriptive variable name for LocalDate instead of d1 could be used? (eg localDate) Noted this issue in several other places too

Can consider renaming the task parameter as taskIndex to make it clearer for users

Could be named better, maybe taskIndexDelete, etc..

Agreed, for now the code is manageable as they are not too much, but if the project expands, it may become hard to navigate.

Comment could be clearer, not sure what it is trying to help with.

Maybe this can be renamed as users might not be able to tell that it is a boolean on first look, maybe taskIsAdded?

Perhaps this nested if-else statement can be combined with the parent if-else statement to reduce nesting?

Perhaps the name here could be changed to something that sounds more like a boolean variable? The same applies to some of the other methods in this file.

This line seems to be one space off?

Perhaps this constant value can be in all caps?

Since the formatter is used multiple times, you can perhaps consider declaring it outside of the if-else statement. Also, since it is a constant, it might be good to name it in all caps.

Maybe imports can be listed explicitly?

Maybe you could add a line break after each case to increase readability?

Should a line be left between the description and @param?

Maybe this method name could be written as a verb, like convertCompletedToNumber or something?

not a violation but - i saw that you used format later but just wanted to remind that DateTimeFormatter can format the output string so there is no need to format manually!

Maybe you can name this method showTaskAdded? I think it is clearer this way.

Similarly, this method can be named showTaskDeleted instead.

Should this variable just be called file instead?

Maybe you can name your tests according to the featureUnderTest_testScenario_expectedBehavior() format?

I think the indentation for these lines should have 4 more spaces. I noticed the same issue in several other places too.

Maybe you could separate this (eg. by assigning String.format to a variable first), so the line wouldn't be too long.

Perhaps you could name it "addTodo" to show that you are adding a todo task to the tasklist, same goes for adding deadline and event tasks. I was reading the "DeleteCommand" file before this and got a little confused by the tasks.deadline method call.

I think you could rename it to "toBeDeleted" or "taskToDelete" to differentiate it from the method call. Same for the other classes.

I think this variable name is a little confusing as well, it has the same name as the method from TaskList. Perhaps you could change it to something more intuitive?

Agreed, List is more intuitive that Ls.

Perhaps you could list the imported commands from this package explicitly?

Should the naming for line be in uppercase since it is a constant? I noticed the same issue in several other files too.

Perhaps you could add line breaks in lines 64 and 65 to improve readability of your code?

Should there be an additional indentation here?

Perhaps you can abstract this logic (and other related logic) to another function (eg. handleDone, handleFind)? This could build better abstraction and improve readability.

Perhaps you could add some Javadocs for the exception classes to explain when each exception is triggered?

Perhaps an empty line should be added here?

Maybe this empty line could be removed?

Perhaps parts of this function could be abstracted out into other functions to make the code more readable?

I like how you made the test names very descriptive.

Perhaps we can rename this boolean variable keepGoing to follow the coding standard style? However in this case, would it be better to use while (true) { ... } and use a break; statement instead?

Should we add a Javadoc comment here?

I like the usage of enumerations here, as it lists out the cases that corresponds to commands and return them. This provides a realistic OOP view of what a parser does in the real world, where it parses the inputs and obtains the commands.

Perhaps we can create new tasks to be added at the AddCommand class, and pass the task to TaskList, that way, it would only need to add it to the taskList?

Perhaps we can add a Javadoc comment here? Or use {@inheritDoc} to inherit parent Javadocs. Think this goes for other overriden methods as well!

Shouldn't the method name be a verb?

If this is a constant name, shouldn't it be in all uppercase letters?

Should this be in PascalCase? ie. TaskList

Should the method name be a verb?

Perhaps the variable name could be more explicit? Same issue for other initiated collection types as well.

A clear idea of method intent is conveyed. However, it would be more coherent with the rest of the names if it was a verb. Maybe something along the lines of getErrorForCommand?

I feel that the class name is a bit ambiguous.

If argument is a single string, maybe this method could be renamed to getArgument?

Consider changing to isPrinted

Consider changing the name to better reflect the intent of the variable. Something along the lines of tasks.

While it is great that you grouped the respective import statements, appropriate spacing could make it easier to browse the list and determine the dependencies, especially since there are many imports.

Indentation for case and default clauses should be removed.

I think this could be an unnecessary use of the "this" keyword. In general, try to use "this" only when a field is shadowed by a method or constructor parameter.

It would be good to declare that the MissingInfoException is being thrown in the javaDoc for the load method.

I love here you changed the indentation of 'case'! Perfect!

Very good you changed readme!

Here I think you can write private final String TASK_TYPE = "T".

I guess these comments may influence reading code 😃

Very good you changed here to match your repository!

Would it be better to implement the logic for each case inside helper methods, and call the helper methods over here, instead of implementing all of the logic in this method itself?

Perhaps it would be better to spell "Parameter" in full to enhance code readability?

Would it be better if a more descriptive name like "writeToFile" is used?

Perhaps it will be clearer to name this test as "load_nonExistingFile_exceptionThrown"

Would it be better to name this isDone?

Deep nesting here. Avoid more than 3 levels of indentation.

Deep nesting here. Maybe can simplify it a little to increase readability?

Maybe can use a line spacing once in awhile to improve readability?

C could be named more explicitly here, maybe just "command".

Is the catch statement supposed to be empty here? If so, perhaps a comment explaining why this is empty would help.

I like the explanation on the usage of the method in Javadocs!

However, perhaps adding a short summary of what the method does would be better, to comply with coding standards. (I also noticed this problem in many places elsewhere, in similar methods)

Perhaps try to shove some code into separate methods? This method seems way too long (although many others do the same).

You might want to put this in a separate else clause, to show that this only happens if the file does not exist.

Maybe can be renamed to getTaskNum() instead.

Good idea to have standard DukeExceptions to recycle.

Comments were useful in explaining an empty catch block.

Maybe you can consider modifying the javadoc for this method or checkUserInput? The purpose of the functions seems very similar to me.

Very good usage of JavaDocs in all of your methods and classes. However, it could be even better if you had a comment explaining the purpose of that particular class. This would help the reader understand what each of the class does to get a better idea, as not everyone uses the same class name to carry out the same function. Very neat comments and javadocs though

Maybe you could have other exceptions extending from DukeException, such as DukeInvalidTaskException, DukeInvalidCommandException. Although in this case, it is not very important, it might become important later on when the code is evolving.

Very good usage of abstraction in order to let one method take care of converting a date. I realise I should have done that as well haha. Good idea!

Very good piece of code, good use of abstraction. But perhaps the naming of certain methods could be a bit more short?. Hahha i'm really scraping the bell here because I can't find anything wrong

The javadocs are clear and easy to understand

The naming of the functions and fields are in the correct form.

The structure of your class is very clean and easy to read.

You may add more test cases to test your code.

When we want to import more than three components from the same package, is it better to use "import dukeclass.*"?

Sorry, I think I have remembered it wrongly 😦 Thanks!

Is it better to use "import java.io.*" since there are more than three import under "java.io"?

Sorry, I think I have remembered it wrongly 😦. Thanks!

Perhaps a couple of line breaks in this function will improve readability?

Perhaps a more intuitive variable name here, such as a noun like date?

I like how you a ReversibleCommand to allow users to undo their commands.

I like the use of streams

The switch statement is clean! But perhaps you missed this coding standard?

The switch statement should have the following form: Note there is no indentation for case clauses.

I like that you did a javadoc comment, but did you accidentally leave a // behind?

Did you accidentally make a linebreak?

This seems like a complicated expression.

Perhaps it would be clearer to separate it? It will improve code quality!

https://nus-cs2103-ay2021s1.github.io/website/se-book-adapted/chapters/codeQuality.html#avoid-complicated-expressions Here's some advice!

Should this be renamed as isDone?

Should the java imports be at the top? I noticed the same issues in several other places too.

Should there be an access modifier? I noticed the same issue in several other places too.

Should the case block have 4 less indentation spaces? I noticed this issue in several other places too.

Perhaps the variable name could be a little more intuitive?

Maybe a noun would be better here?

Perhaps you can use plural form for names representing a collection of objects?

I like how you did not indent the case clauses

Perhaps these variable names could follow the format for naming constants?

I noticed that similar header comments have been written for this method in the other classes that implement this interface. Not sure if its just me but, I feel that it suffices to write a general description of this method here and omit the comments in the other classes!

Looks like indentation is slightly off here!

Perhaps a general header comment can be written for this execute method? That way, comments can be omitted for the execute method in the other command classes implementing this interface!

Also, I noticed the header comments of this method in the other command classes do not have the @ return line!

Perhaps can break up this method into shorter methods?

I agree with @xxzz-tt. Perhaps you could abstract away lines 24 - 28 to be in the respective task commands?

Perhaps you could rename the variable c to command instead? to make line 43 and 47 clearer

Would it be clearer to name this variable as commandAndArgs ?

I like how you use at as a variable name here, similarly for deadline class

for boolean values, i may recommend using isStart/hasStart or isEnd/hasEnd as suggested by the coding standards

Yes, he should use single class imports instead of wildcards

perhaps the use of a switch statement may be better here.

There are a number of try catch blocks within each if block, perhaps it might be possible to use a wider try catch block with more catch blocks to deal with multiple exceptions, or handle them simultaneously since the exceptions are handled similarly.

You can use assert(!event.getStatus()); here as well, just to make the code slightly cleaner, similar comment for line 20. The rest looks good, great job!

Should this class be named as Main? I personally feel a bit confused as you have classes MainWindow, Ui and Duke as well and I expected main() method to be in this class. Would you consider something like DukeGUI?

Should the Ui class be implementing these methods? As these are "response messages", I think they might be better implemented in the DialogBox class.

I like how clean the code here is, good job on that!

Following the naming convention, should the method name be a verb instead of a noun? A few suggestions from me would be markComplete, getMarkCompleteString, getMarkCompleteMsg. I spot this for a few other methods in this class as well.

Cleanliness-wise I like how clean the code is! Very readable. Good job!

The comments in this part are a little confusing -- there are two "Step/part 3. Add functionality to handle user input.", which makes it look a bit like you accidentally duplicated your code or forgot to delete one of them 😢 Perhaps make these comments more descriptive?

Really minor cosmetic suggestion -- the empty lines for your if / else if blocks are perhaps not necessary? I think it's up to you, but in some sections (including earlier in your code), you forget to leave an empty line at the end of the block 😊

You could leave a space between 'else if' and '('!

I like the naming of your method "startsWith" for input as it sounds very intuitive.

I think having an enum class for duke exception types is a great idea! 😃

I don't know if it's possible but perhaps a package could be used to group all these different types of command together? Then you'll only need to import a package 😃

I like the way you format the messages, it makes your code a lot more readable!

Nice that the constants are properly labelled: public static final followed by an all caps name.

Nice job on the switch case indentation

Nice work on the switch case indentation

Maybe you could add description for less understandable param names

Since the logo and the greeting is constant maybe they should be static instead? And since they are static then the names should adhere to the naming conventions!

Maybe the type of the event represented by the "E" here should be static since it's a constant?

Maybe the type of the event represented by the "T" here should be static since it's a constant?

Maybe the D representing the task type can be a represented as a constant instead i.e TASK_TYPE? This applies to the other tasks as well.

Perhaps a switch statement here instead of if else?

Would it be better to extract the code in each if else block into a separate method to keep the getResponse method short and easy to understand?

Do you mean get instead of gett?

Very good use of command abstractions. Clear, organized and easy to understand!

Perhaps you could have exceptions extending from DukeException? (Such as DukeInvalidDateFormatException). This may help to distinguish between different types of DukeExceptions thrown.

Perhaps the method name could be more specific? E.g viewAllOnDate

there should be underscores to separate words for constant names, eg. FOLDER_PATH and FILE_PATH

Names representing methods should be in present tense instead of past tense eg. deleteTaskDescription, addTaskDescription

constant names should be in uppercase eg. DIVIDER

Consider storing your symbols (e.g. "[D]") as a constant final string DEADLINE_SYMBOL = "[D]". Might be more convenient for you should you decide to change it later on.

I feel that a 'if-else' statement to check whether the storage file exists is more suited here, rather than using 'try-catch'.

As such, I might rewrite it as follows:

'''java

File file = new File(filePath);

if (file.exists() && file.isReadable()) {

tasks = new TaskList((new Storage(file)).load());

} else {

tasks = new TaskList();

}

'''

Of course, this means that your 'Storage' class constructor should take in a 'File' rather than 'String' which I'll talk more about later.

'''

Would you name all your static variables in capital letter?

would you name all your static variables in capital letter?

iP review comments dashboard

1. LIM ..YANG @Ziyang-98 (59 comments)

2. FIDE..JOJO @ZoroarkDarkrai (54 comments)

3. WEN ..NHUA @jh123x (53 comments)

4. CHON..A LE @chiabs (52 comments)

5. CHEN..IHAO @howtoosee (50 comments)

6. CHEO..LARA @claracheong4 (47 comments)

7. TIN ..SAAC @IsaacTin (44 comments)

8. FLOR..TINA @florenciamartina (43 comments)

9. AUGU..CONG @augustinekau (43 comments)

10. ANIK..ARAM @Ebolaeater (42 comments)

11. ZHAN..NLIN @ZhangWanlin98 (38 comments)

12. WONG..LONG @junlong4321 (37 comments)

13. NOOR.. H U @itssodium (36 comments)

14. YE J..DONG @yejiadong (33 comments)

15. KOR ..SOON @kormingsoon (33 comments)

16. HUAN..NGYU @HCY123902 (31 comments)

17. TAN ..INXI @FizzyAgent (30 comments)

18. JONA..O EN @jonasngs (29 comments)

19. LAU .. SAM @silvernitro (28 comments)

20. CHRI..FUNG @chrisgzf (28 comments)

21. TEE ..IANG @teekoksiang (27 comments)

22. LAM ..YUAN @lamlaaaam (27 comments)

23. MASA..ASIS @erisjacey (27 comments)

24. CEDR.. WEI @Cedo8 (27 comments)

25. NEIL..UPTA @Jargonx (26 comments)

26. FOO ..I EN @wakululuu (26 comments)

27. LI J..IAYU @lll-jy (26 comments)

28. ERIN..AWAN @erinmayg (25 comments)

29. LIU ..GDAO @justacasul (25 comments)

30. YEO .. XIN @pockii (25 comments)

31. LIM ..HENG @JunCheng98 (24 comments)

32. KOH ..LING @ruilingk (24 comments)

33. LIM ..NEST @ernestlim8 (23 comments)

34. TAN ..IANG @wltan (23 comments)

35. LIM ..HONG @qwoprocks (23 comments)

36. YEH ..CHUN @peter-yeh (23 comments)

37. KENN.. KAI @kswk (23 comments)

38. VUON..LONG @UncleGrandpa925 (23 comments)

39. AMY ..TING @amylzting (23 comments)

40. WU Z..YING @zeying99 (22 comments)

41. GAN .. WEN @gan-jw (22 comments)

42. GALV..YUAN @galvinleow (22 comments)

43. KIMB.. QIN @kimberlyohq (22 comments)

44. ZHOU..JIAN @BobbyZhouZijian (22 comments)

45. TAN .. JOE @tjwjoe (22 comments)

46. ROY .. ZHI @royleochan (21 comments)

47. MARC..G YU @Marcon2509 (21 comments)

48. ZHAN..NJIE @Zhang-Yunjie (21 comments)

49. YAP ..IANG @akgrenSoar (21 comments)

50. LEE ..G DE @LeeMingDe (21 comments)

51. JOSH..NGYA @joshualiangxy (21 comments)

52. ZHU ..XUAN @yuxuanxc (21 comments)

53. DORA.. QIN @Door-oof (21 comments)

54. KWEK.. YIH @hakujitsu (21 comments)

55. TIMO.. KAI @timjkong (20 comments)

56. LE Q..TUAN @youaremysky99 (20 comments)

57. TOH ..ANNE @jeannetoh99 (20 comments)

58. LYE ..XIAN @lyeyixian (20 comments)

59. LIM ..KIAT @limkoonkiat (20 comments)

60. AMEL..N YU @ameliatjy (20 comments)

61. DANI..NOTO @danadi7 (19 comments)

62. TOH ..OLAS @nicktohzyu (19 comments)

63. SHI .. LIN @aqcd (19 comments)

64. HOGA.. HAN @hogantan (19 comments)

65. KISH..UMAR @KishenKumarrrrr (19 comments)

66. GIDI..AHUL @Rahul0506 (19 comments)

67. TENG..LING @tengjianling (19 comments)

68. TRAV.. WEI @Trav1sT (19 comments)

69. LIU ..MING @richardcom (18 comments)

70. CAI .. LIN @jialin7878 (18 comments)

71. MARC.. WEI @MarcusTw (18 comments)

72. JONA..N ZI @jonahtanjz (18 comments)

73. KEVI..LIAM @kevnw (18 comments)

74. DHAF..UZAN @dhafinrazaq (18 comments)

75. THEO..RANT @theodoreleebrant (17 comments)

76. DIAN.. HUI @dianneloh9 (17 comments)

77. HO P..XIAN @hopinxian (17 comments)

78. LU L..UOYI @luo-git (17 comments)

79. LOW .. LIM @Avalionnet (17 comments)

1. LIM ..YANG `@Ziyang-98` (59 comments)

2. FIDE..JOJO `@ZoroarkDarkrai` (54 comments)

3. WEN ..NHUA `@jh123x` (53 comments)

4. CHON..A LE `@chiabs` (52 comments)

5. CHEN..IHAO `@howtoosee` (50 comments)

6. CHEO..LARA `@claracheong4` (47 comments)

7. TIN ..SAAC `@IsaacTin` (44 comments)

8. FLOR..TINA `@florenciamartina` (43 comments)

9. AUGU..CONG `@augustinekau` (43 comments)

10. ANIK..ARAM `@Ebolaeater` (42 comments)

11. ZHAN..NLIN `@ZhangWanlin98` (38 comments)

12. WONG..LONG `@junlong4321` (37 comments)

13. NOOR.. H U `@itssodium` (36 comments)

14. YE J..DONG `@yejiadong` (33 comments)

15. KOR ..SOON `@kormingsoon` (33 comments)

16. HUAN..NGYU `@HCY123902` (31 comments)

17. TAN ..INXI `@FizzyAgent` (30 comments)

18. JONA..O EN `@jonasngs` (29 comments)

19. LAU .. SAM `@silvernitro` (28 comments)

20. CHRI..FUNG `@chrisgzf` (28 comments)

21. TEE ..IANG `@teekoksiang` (27 comments)

22. LAM ..YUAN `@lamlaaaam` (27 comments)

23. MASA..ASIS `@erisjacey` (27 comments)

24. CEDR.. WEI `@Cedo8` (27 comments)

25. NEIL..UPTA `@Jargonx` (26 comments)

26. FOO ..I EN `@wakululuu` (26 comments)

27. LI J..IAYU `@lll-jy` (26 comments)

28. ERIN..AWAN `@erinmayg` (25 comments)

29. LIU ..GDAO `@justacasul` (25 comments)

30. YEO .. XIN `@pockii` (25 comments)

31. LIM ..HENG `@JunCheng98` (24 comments)

32. KOH ..LING `@ruilingk` (24 comments)

33. LIM ..NEST `@ernestlim8` (23 comments)

34. TAN ..IANG `@wltan` (23 comments)

35. LIM ..HONG `@qwoprocks` (23 comments)

36. YEH ..CHUN `@peter-yeh` (23 comments)

37. KENN.. KAI `@kswk` (23 comments)

38. VUON..LONG `@UncleGrandpa925` (23 comments)

39. AMY ..TING `@amylzting` (23 comments)

40. WU Z..YING `@zeying99` (22 comments)

41. GAN .. WEN `@gan-jw` (22 comments)

42. GALV..YUAN `@galvinleow` (22 comments)

43. KIMB.. QIN `@kimberlyohq` (22 comments)

44. ZHOU..JIAN `@BobbyZhouZijian` (22 comments)

45. TAN .. JOE `@tjwjoe` (22 comments)

46. ROY .. ZHI `@royleochan` (21 comments)

47. MARC..G YU `@Marcon2509` (21 comments)

48. ZHAN..NJIE `@Zhang-Yunjie` (21 comments)

49. YAP ..IANG `@akgrenSoar` (21 comments)

50. LEE ..G DE `@LeeMingDe` (21 comments)

51. JOSH..NGYA `@joshualiangxy` (21 comments)

52. ZHU ..XUAN `@yuxuanxc` (21 comments)

53. DORA.. QIN `@Door-oof` (21 comments)

54. KWEK.. YIH `@hakujitsu` (21 comments)

55. TIMO.. KAI `@timjkong` (20 comments)

56. LE Q..TUAN `@youaremysky99` (20 comments)

57. TOH ..ANNE `@jeannetoh99` (20 comments)

58. LYE ..XIAN `@lyeyixian` (20 comments)

59. LIM ..KIAT `@limkoonkiat` (20 comments)

60. AMEL..N YU `@ameliatjy` (20 comments)

61. DANI..NOTO `@danadi7` (19 comments)

62. TOH ..OLAS `@nicktohzyu` (19 comments)

63. SHI .. LIN `@aqcd` (19 comments)

64. HOGA.. HAN `@hogantan` (19 comments)

65. KISH..UMAR `@KishenKumarrrrr` (19 comments)

66. GIDI..AHUL `@Rahul0506` (19 comments)

67. TENG..LING `@tengjianling` (19 comments)

68. TRAV.. WEI `@Trav1sT` (19 comments)

69. LIU ..MING `@richardcom` (18 comments)

70. CAI .. LIN `@jialin7878` (18 comments)

71. MARC.. WEI `@MarcusTw` (18 comments)

72. JONA..N ZI `@jonahtanjz` (18 comments)

73. KEVI..LIAM `@kevnw` (18 comments)

74. DHAF..UZAN `@dhafinrazaq` (18 comments)

75. THEO..RANT `@theodoreleebrant` (17 comments)

76. DIAN.. HUI `@dianneloh9` (17 comments)

77. HO P..XIAN `@hopinxian` (17 comments)

78. LU L..UOYI `@luo-git` (17 comments)

79. LOW .. LIM `@Avalionnet` (17 comments)

80. WINC..TJOI `@Wincenttjoi` (17 comments)