iP review comments dashboard

Would it be a good idea to add a comment to explain the unicode so that people know what you are returning?

To me it seems a little unintuitive as to what D might mean if it's my first time seeing the code, perhaps you could make it an attribute of the Deadline class?

I agree with Hazel on this, the same could be done for BY_AT_LENGTH as well.

To add on, List is an interface in Java so perhaps avoiding list would be a better idea since you are using an array in this case

continue appears here but not in subsequent else if statements, perhaps you could standardize across the whole while loop?

I don't think there is a need for concatenation here, as "\t " should work just fine

I like how u split the singular and plural cases

I like that you have a separate method to printing the divider line as it is frequently used

Same as in the Deadline class and the rest of the classes

I notice that ToDo doesn't override the getStatusIcon method from Task, whereas Deadline and Event does. Is this intended? And also since Task will never be called in your program, would it be better to just delete the overriding methods and just make the change in the method in the Task class?

Should [D] be a constant in the class so that it is clearer what it means? Like each subclass of Task can have a taskType?

I think that divider can be named in all caps, since it is a constant.

5 seems like a magical number here. Would it be better if you change it to get the index of the start of the task name?

Same as addToDo, not sure how 9 is derived without knowing the command syntax

Could the 4 possibly change if the user enters a typo?

Same as addToDo

I think that this can be all caps as well since it is a constant

When using contains(), would there be a case where todo get homework done triggers this and thus create an exception where 'get homework done' cannot be converted to an int?

Same as Deadline class

If you're just returning an X, would it be better to just use 'X' so that the confusing unicode can be avoided?

I think that it would be good to standardize having a newline at the end of file for all files

I like that you added the Override tag so that it's immediately clear that this method is being overridden

I think that 2 blank lines is enough between import statement and the rest of the code

There is an extra indentation for the case block

Good coding standards for if else blocks

Naming convention for methods and variables are all aligned with the coding standards

Good naming conventions for boolean

Might be slightly unclear the usage of the variable

This class is very well made and well thought out. Well done!

Can consider putting the welcome message into a function for increase readability

can consider using a general function to deal with each possible command (OOP way), instead of a sequential code.

The code in this block is slightly confusing. Maybe can include some comments or group them into a function with a function name that details the purpose of the function

Consider using switch statements instead of if-else.

Nice and efficient coding.

Good and efficient code

Using switch statements will improve your code quality!

Can consider creating a class to parse the information from the cmd line

Good code quality, simple yet efficient

can define this pretty print line as a constant

Good class to have in order to separate the error checking!

Good use of constant for pretty printing

maybe can think of more functions for user interface

Since this is found in the user interface, maybe can consider removing this and call from the user interface class instead.

This block of code is very clean. Simple and easy to understand! Well done!

Should there be one more space between "Task" and "{" here? I noticed a similar issue (though very minor) in line 5 of Deadline.java as well.

Should there be one more space between "Task" and "{" here? I noticed a similar issue (though very minor) in line 5 of Event.java as well.

Should there be one more space between "Task" and "{" here? I noticed a similar issue (though very minor) in lines 18 and 22 of Task.java as well.

Should there be one more space between ")" and "{" here? I noticed same issue (though very minor) in several other places of Duke.java too.

Perhaps you could further improve consistency by considering having a space before and after “+”, just like “byIndex + 4” here because you do so in other parts of your code such as in line 39 (“\t” + t)? 😃

Perhaps you could consider using "inputs" (plural forms are used on names representing a collection of objects) as the variable name after splitting taskDescription? 😄

You might tweak your code a bit to make your for loops look like this:

for (int i = 0; i > nElements; i++) {

// Code

}

You could consider having a space between "while" and "(condition)" 😃

Same thing here, perhaps you could consider having a space between "if" and "(condition)" as well 😃

Hey, I like how clean this bit of code is 👍

Should there be one more space between "Task" and "{" here? I noticed a similar issue (though very minor) in lines 3 and 7 of Todo.java as well.

Great naming for variables!

Very descriptive and appropriate naming for functions!

Very succinct code with high readability, well done! 😃

Well done! You could consider using a named constant for 100, say "MAX_TASKS_SIZE".

It seems like there is an additional space between "super.convertToTaskOutputString()" and "+".

Very logical action here. Perhaps you could consider using "commandAndTaskNumbers" (plural forms are used on names representing a collection of objects) as the variable name after splitting input? 😄

Hey, I like how clean this bit of code is 👍

I like the fact that you wrote clear comments for some variables and all methods used. 😄

Mixing if and case statements affects readbility of code as there are multiple conditional statements (nested conditional statements)

Can merge into a single line

Can consider renaming addedTasks to tasks to enhance readability

Readability can be enhanced

Avoid using a conditional statement in a single line

Avoid mixing if statements and case statements as readability may be affected.

Method name is appropriate

switch case statement indentation needs to be fixed.

readability can be enhanced here, perhaps one line per newline

Can be merged into a single line to enhance readability

the name tasks can be considered for the name of the array to show that the array contains multiple tasks

Case statements are clear

Refactoring done here enhanced readability

Avoid assigning null value to variable

description and by variables appropriately named

Can consider separating the \n to enhance readability

Since the Strings referenced by both "logo" and "divider" variables will never change, perhaps you can consider declaring them as constants instead, by capitalizing both variable names and adding the "final" keyword to them.

Perhaps you can rename "inputData" array to something like "arguments", so as to adhere to the coding standard of "Plural form should be used on names representing a collection of objects."

I believe a "default" case should be added here, so as to adhere to the coding standard on using a switch statement.

This highlighted block of code can be placed in a separate method since it has been repeated among the cases of "deadline", "event" and "todo".

Perhaps you might want to first declare the array size as a constant, then use the constant to initialize your array so as to improve your code readability and thus the quality. This is also to satisfy the code quality section on "Avoid Magic Numbers".

Varying levels of abstraction.

The abstraction level of this entire block of code, when compared with "UI.showWelcomeScreen();" at line 7, has different levels of abstraction. Perhaps you may want to shift the switch statement to a separate method, so as to achieve "Single Level of Abstraction Principle".

This method exceeds 30 LOC and hence violates the code quality guideline on "Avoid Long Methods".

Varying levels of abstraction.

Perhaps it will be great if you can shift line 19 to 22 and the switch statement to a separate method each, so as to achieve "Single Level of Abstraction Principle".

The word "Customised" is a British spelling and violates the coding standard of using American spelling only.

Perhaps you may want to correct it to "Customized" instead.

I like how you personalize your chatbot with a name.

I think there is a minor wording issue with the phrase "personal assistance chat-bot" in your comment. Perhaps you might want to rephrase it to "personal assistant chatbot".

I agree on this too! The way you list your imports explicitly allows future collaborators to know exactly what libraries they need to be aware of before working on your code.

I like the way you standardize the declaration of the constant TASK_TYPE across other subclasses of Task.

The way you name, capitalize and declare the constant TASK_TYPE adheres very well to the coding standard and convention, well done!

I believe a "default" case should be added here, so as to adhere to the coding standard on using a switch statement.

The naming of this method can be further improved as the current name does not sound like a boolean. This violates the coding standard of "Boolean variables/methods should be named to sound like booleans".

I believe a "default" case should be added here, so as to adhere to the coding standard on using a switch statement.

Perhaps you could rename the variable to hasRun which meets the coding standard for boolean

Perhaps you should not have added 4 more indentations here as initially, it was 8 indentation which fulfills the coding standing

I like your format of a switch statement which follows the coding standard

Good job for following the coding standard

Perhaps you could extract the switch statement into a method for better code quality

Perhaps you could mention that you are overriding the toString method in the parent class

Maybe you could give input.indexOf(' ') a name to improve readability

Perhaps you could also add a greetings method to improve readability

Perhaps you could add the else if statement to the above line to follow the coding standard

Good use of switch statement to follow coding standard

Perhaps you could put else statement to be more clear and follow coding standard

Good use of commenting fall through which follow standard

Perhaps you could give this method a different name?

Good use of namings and use of Single Level of Abstraction Principle in the method

There should be a space after the condition before curly bracket

Constant name should be all caps

Add a space before and after the else and curly brackets

You have already declared Newline so you can use it here

Hello, functionality looks good! However, I suggest formatting into more methods such as checkDone so you code looks cleaner

Leave a space before and after curly bracket

I believe constant names must be all in uppercase

you can just Case "D" and Case "E" to return the description.substring instead of returning from case D and Case E individually

You can maybe format this into another method to make your code cleaner

You need to add a space after curly bracket and before the curly bracket

Hello, I believe a constant must have all caps.

You need a space after the else statement before the curly bracket

Add a comment to the method

All comments on a method should start with a /** and end with a */ format.

Good and consistent usage of PascalCase for naming of classes

Good and consistent usage of camelCase for methods

Consistent and proper indentation and bracketing for if-elseif statements

Good job on not exceeding line limit

Good method name. Clear and concise

Good if-else structure. Short and concise.

Good definition for methods.

Good usage of OOP. Makes code clear and easy to understand.

Comment at the bottom helps understand what line above means.

Complicated expressions. Takes reader time to decipher what code means.

Try to avoid nested if-else conditions. Gets confusing

What does slash mean? Definition is not really clear, can be confusing.

Can be confusing due to long expression. Takes reader time to decipher what it means.

Interesting how you personalized the readme file! Nice brief introduction, just a minor typo at line 5

Nice clean main method.

Good use of understandable constants. Seen in other parts of the code as well.

Inconsistent spacing after if statement, before the conditional. Also seen with some for loops.

Perhaps use multi-line comments instead of single line comments? Might look neater!

Good child class implementation!

Or perhaps you could include the logo and line 10 printing in the greet() method?

Suggestion - maybe refactor this part into a method "getInput" to align with the SLAP Principle

Maybe could consider using a more detailed name? Like printLine(). end() sounds ambiguous and could mean terminating the program

The variable name on does not have much meaning to a reader. Maybe consider changing it to a name which describes it's function? Like "description"/"taskDescription"

Can I suggest:

Instead of doing the +1 inside (line 13)

System.out.println(count + 1 + ": " + TaskManager.tasks[count]);

Maybe you can initialize count = 1? I don't think there's anything wrong with your implementation, just for your consideration!

Method name can maybe be better defined? getCommand(input) is not actually getting any command but is parsing the input into the respective fields.

Detailed and clear method naming!

I like how clean this class is, there are no redundant functions here. Also, no coding violations here. Well done! (:

This is the correct if-conditional layout with the 'break' in a separate line, well done!

This is the correct if-conditional layout. Perhaps you could consider using a "switch" statement instead?

I found no coding violations here. Well done! (:

I like how clean this class is, there are no redundant functions here. Also, no coding violations here. Well done! (:

This is a correct formatting for switch, good job for keeping that in mind!

This is the correct try-catch layout, good job!

This is the correct if-conditional layout with the 'break' in a separate line, well done!

Should this while loop be extracted out? I think it might be cleaner if abstracted

Good job with the internal abstraction, very neat!

I am not sure if you should do the try{function} catch error instead of having the try catch in the function itself. perhaps it would be better to try the function instead

I think you could add in "@Override" above this?

May wanna add some error handling if user enters a task number that is out of range

Nice! Clean use of inheritance

Collection of Task objects "tasks" is in plural form, good naming convention!

Switch statement follows the Java coding convention, good work!

Good use of name for boolean!

Very readable and easy to understand, nice

Naming a task object "temp" may be confusing to readers. May want to specify what exactly is this Task Object

Great Job! Constants are in Uppercase and are very readable

May want to change to something like "isDeadlineValidated" to make it sound more like a boolean

May want to change to something like "isTodoValidated" to make it sound more like a boolean

Switch statement follows the Java coding standard, good job!

Collection of Task objects "tasks" is in plural form, good naming convention!

A constant name should be in capital letter

the naming here is a little confusing, it might be better if you use something like "doBy" or "finishBy".

well done! the branch is in correct format and correctly follows SLAP

it might be better if declaring "\u2718" as a string constant at the beginning. although you add comment here, it looks like a magical literal.

the naming is a little confusing as the member variable has the same name as the class

the print message part is repeated in addTodo, addDeadline and addEvent, maybe you could consider making it a separate method.

it would be better if the collections are named as plural

the condition should be put in a single line

the layout doesn't follow code standard. The standard format should be:

if {

} else if {

} else {

}

the "------------" is like a magic literal, it might be better if making it a string constant with meaningful name

it would be better if follows SLAP in this section

the try catch clause doesn't follow the format in coding standard

It's quite good to introduce a method for the separation operation so that dealing with input is divided into small tasks.

I have a doubt here. Should taskCounter be maintained here? What if the user did not type in a correct format like without a "/by " phrase, but it is still counted.

I think the expressions here are pretty straightforward, only that they are not in the same format. What I mean is they don't look like parallel statements. These recognition for keywords part might be optimized later on.

Very neat for calling super toString method.

The constant string above are very readable. This is good.

It is function overloading, I think is quite straightforward. But can also separate into "printList" and "printResponse" as they are quite different as in the incode- comments.

constant string naming should be all UPPERCASE

The method names are all in camelCase. It's good.

Plural forms for arrays are good.

Indentation is four spaces, it's the correct layout.

Consider putting else if statement on the same line just after the previous curly bracket.

Better if you put the //comments on a different line with indentation.

Hi, I like the way you tokenize your inputs before passing them into the function. And maybe assigning them to a specific string is before passing would be easier to read compared to the array item itself?

I believe conditional statements should be placed on a separate line and wrapped with curly brackets even if it is just a line of code. 😃

I like the way that you declare a constant here to make the code clean! And good job remembering the format. Most of us would just forget it.

I noticed that you use inheritance for all the other subclasses and it's clean and easy to read for each individual subclass. Keep up the good work!

You may want to have a more definite name here for the Task array instead of just t as it might get confusing later on

I like the way that all 3 methods are of the same naming convention to show that they are doing similar tasks. But I think the naming can be changed to make it slightly clearer? Like "addDeadline" etc. as enter might be misleading depending on subsequent functions created to key in deadlines. 😃

I like the way you introduced a new class to house the logo and the UI of your program.

There is quite a few functions within the same line. Maybe we can split it to different lines to improve readability and understanding?

Nice use of documentation here to explain the functions and parameters passed into the method!

I am not too sure on this myself but, maybe you can start a comment with the "//"? As "/**" is used for Java documentation on methods?

Great use of constants! Do always remember the naming convention as what you are already doing! 😃

You may want to use a constant to replace the number 4 here (or maybe a comment to explain) as other's may not understand why we have to offset 4 from the date index itself.

Good use of methods to follow Coding Quality.

Good use of try-catch statements!

Good use of methods to make code cleaner!

Can consider keeping the code in main more abstracted

Can consider abstracting these conditionals into methods or booleans

Can consider abstracting these checks into methods for clarity

Good use of switch and case

Consider clarifying what these "Details" are, for clarity

Good job on following coding standards for if-else!

Can consider using a clearer name for "sc"

Agree with this comment.

can remove the blank line

looks clean!

new line after bracket

looks good! easy to understand

another blank line here

looks good for the coding standard

Maybe do not use the shortcut for the String

Maybe can try other names for boolean

good changes! looks clearer

datatype and name seem a bit confusing

everything is good here

if-else statements follow coding standards closely. However, you can consider using case statements to implement this huge if-else block

Interesting naming convention, I think "Doby" sounds cute but maybe "DoBy" would be clearer?

perhaps you can rename this setTaskDone to something else? I almost thought it looked like a recursive function until I noticed the method setTaskDone in the Task class also

This -1 seems slightly out of place, maybe you can replace it with a static final variable or a constant? I could not tell the reason for it.

Really consistent if-else nesting, but a case statement may be more helpful here!

If else statements should also follow proper coding standards! ie.

If {

} else if {

} else {

}

Funny and interesting comments! However, you should probably follow the coding standards on comment formatting going forward!

Similarly, this try-catch handler could be formatted better in the following way:

try {

statements;

} catch (Exception exception) {

statements;

} finally {

statements;

}

These texts are great for adding personality! But they seem slightly long and may be violating some coding standards 😃

Your Duke class is looking really long! Maybe consider breaking it up further into separate classes! That would help readability a lot!

if you want to get rid of the annoying blank spaces that sometimes show up in Strings, perhaps you can consider using String.trim() to format the string into something shorter!

It would be good practice to keep the indentation for wrapped lines to: 8 spaces more than the parent line.

Very clean code! Looks good to merge

Perhaps you can use plural variable name for representing the collection of Task objects. Even though taskList is quite clear and can be easily understood, use of plural word like "tasks" could better convey the meaning.

Any reason why you have not included ".by" with 'this' keyword? I think it would be better practice to specify which attribute the calling object is accessing and not to just directly access this object.

Using "rd" as the Random object name seems to be vague and might not go by the naming convention. Instead you can use a more specific word like randomNumber that provides better readability and explanation to what you are intending to do.

All variables, methods, boolean values follow the coding standard by use of appropriate casings! Looks neat 😃

For wrapped lines, maybe you can consider indenting with 8 spaces more than the parent line.

This method is not used anywhere in the program. Maybe you might want to invoke it whenever you need to access the "description" variable but since you have used the toString() method to achieve that purpose, you can omit this method.

This method has not been invoked in any other part of the code, so if it isn't used, perhaps you might want to omit to avoid having dead code.

Instead of using nouns such as loopOperation as the name of your method, perhaps you could use verbs like: operateLoop(). This would make it more understandable for the readers.

During fall-through cases, where there are no break statements, it is good practice to include a comment like //FALL-THROUGH.

Iterator variables can be called i, j, k etc. In this case, use f instead of fragment.

The comments should end with a full stop.

Add // Fallthrough comment for cases that does not have break.

Plural form should be used on names representing a collection of objects.

Variable names could be more understandable if the naming is more descriptive (e.g. COMMAND_MARK_WORD) to know that the constant is a command word.

There should be an empty line between description and parameter section. Comments should also have full stop at the end.

variable names should be in camel case.

Function name could be more descriptive of what the function does (does it print a standard string or borders, etc.). Perhaps using printBorderLine() would be better instead.

Variable naming should be clear. In this case, perhaps totalNumberOfTask works better.

Agree. It shows exactly what the program would do at a top level without clutter. However I think that loopCommands() method could be named better. Could use a while loop with executeCommand() and include the getCommand() method here instead. This is to show that the program prints a welcome message, takes user input, executes some commands from the user input, then exit after loop is escaped. Instead of just looping some commands with loopCommands().

Could put these strings into a constant to make reading and future editing of such strings easier (e.g. final static MESSAGE_SET_TO_DONE). Applies to the other message strings as well.

Might want to add spacing between "if" and '('

I like how you seperated the task portion of the code with a task manager

Perhaps "sizeOfTasks" can be renamed to "capacity" for consistency with Duke.java and to prevent confusion with "numOfTask" below

Perhaps a more intuitive name for "taskIndexShow"?

Perhaps you can combine the strings so that you only need to use one println

Perhaps you can refactor this method based on the different types of tasks to make it shorter

Perhaps you can consider using ".startsWith" so that you won't have magic numbers

Same for the other if statements below

Perhaps you can remove tasks as a parameter

The method should be able to access the arraylist even without having it as a parameter

Perhaps you can give it a name like "deadline" instead of just 'd'

Might want to declare a constant for the value 5 with a name that matches its purpose

Can I check if isDone status is implemented for printing of deadline and events?

It seems like the "getStatusIcon" method is only used in Todo

Well done on providing named constants

Have you considered using String.split() method for finding the task description?

Consider refactoring this switch case. The execution path taken when everything goes well should be clearer here. Consider wrapping each outcome into a method that best describes the outcome

Have you considered using named constant variables for the symbols?

Well done on making a UI class specific for the output

Have you considered using short-forms for variable names?

Indentation for this switch case is done well

Method names are verbs and camel case, well done.

Boolean variables sound like booleans, well done

Well done on using the plural form for a collection of tasks

Maybe the naming of this keyWordBeforeDeadline can be changed to deadlineTaskContent to be more meaningful & readable?

I like this organization in the main method!

You may want to use switch to replace multiple ifs here

Maybe you can use auto-formatting to ensure the positions of braces are consistent.

Maybe instead of using the static method, encapsulate this as a public method of the Event class can be more handy

Should this be extracted out as something like if(hasTask()) for better readability?

Should this be extracted as a method to get the taskType and taskToAdd from the input?

Maybe we can make the task type a protected attribute instead of overriding the return value of this method?

Maybe instead of event, use a verb for method names (e.g. addEvent)

This method does more than getting input, maybe can use a more appropriate name?

I like how you followed the coding standards and define "D" as a final string constant. I see this in other places as well.

I like how your methods name are self-explanatory. I see this in other places as well.

I like how you followed the coding standards and split long lines into shorter lines. I see this in other places as well.

I like how you extract the methods out for the main program. I see this in other places as well.

I like how you put curly bracket although there is only one statement inside. I see this in other places as well.

I like how your 'if' statement isn't too deep. It is easy to read.

I like how you abstract out methods. I see this in other places as well.

I like how you avoid "magic numbers" and define them as a variable. I see this in other place of your codes as well.

Should this be extracted out?

Should "D" be defined as a final string variable? I see this in other places as well.

Do you think "D" could be introudued as a static final constant?

Is it possible to avoid the "nested if" blocks?

Do you think "taskArgs" coukd be renamed as "taskArg" since it is singular?

Will it be better to use the standard class "Stringbuilder"?

Do you think "E" could be introudued as a static final constant?

Do you think "T" could be introudued as a static final constant?

Would it be better if these lines of code are extracted to static methods?

e.g. showWelcomMsg(), showByeMsg(), showHelp(), ...

Would it be better if user input checking is done inside corrisponding methods?

e.g. check wherher "input.contains(" /at ")" is true within addEvent(input)

No redundant method is introduced. Good!

Import only the necessary library. Good!

The name 'print' might be overused here - maybe can consider just renaming to lineWithNewLine or even better, have a static UI class! Then you can just UI.lineWithNewLine

Perhaps instead of naming the String arg. line, maybe can call it userInput?

Perhaps can be more specific about the naming - rename to taskNumber, perhaps?

Hmm maybe rename to eventDate?

Perhaps can rename to deadlineDueDate?

perhaps can consider renaming to endProgram() - more succinct 😃

Perhaps renaming all the MESSAGEs to lead with the noun first? e.g. MESSAGE_ERROR and MESSAGE_LIST_FULL

Maybe can consider renaming to MAX_ENTRY_LENGTH? This can apply to all the classes of Task, right?

Nice that you have a help function!

Good class names - follows coding standards but maybe can just call it ToDo instead?

Yups, if should have curly brackets even If it's a one-liner

comments should be indented relative to their position in the code

perhaps u can create a Ui class to hold all the things you want to print

Abided by the coding standards, well done!

Good java coding standard

I like the way that you declare a constant here to make the code clean! And good job remembering the format. Most of us would just forget it.

good job on importing only what u need

I noticed that you use inheritance for all the other subclasses and it's clean and easy to read for each individual subclass. Keep up the good work!

perhaps can create a Ui class to hold the things you want to print I.e greetings, divider etc

Good job on using constants

Inconsistent spacing with regards to operator. Should be 1 spacing before and after operator.

Can be split into more lines to improve readability.

Inconsistent format for naming constants, some have _ in between words but not this time.

Inconsistent spacing before and after commas.

Spacing after if.

Should have spacing before and after operator.

Variable name can be more descriptive, ind maybe too vague.

Variable name can be more descriptive, cmd maybe too vague.

spacing before and after operator.

Good job putting comments.

This part is good as many tends to forget the point on keeping your single line of code short (lesser than 120). This also makes it very readable.

It better to have a space after the (true) for consistency

there is no need for a blank line (i think?)

extra space after the (content), you might want to consider to remove?

maybe it is just me but maybe you can try to avoid the nested if else loop if possible? (the arrowhead thing)

There is some multiple blank line. (maybe you might want to remove it?)

not sure but java coding standards mentioned something on the .equals. Not too sure if this applies to your case.

Maybe you can consider if you want to change from if else to switch statements? such that your default will return null.

Maybe this can be done by the constructor? assigning of value to the variable taskCount

Maybe you might want to use constant for the keywords? Such that any future changes to the keywords can be edited easily. (not too sure)

Perhaps you could consider starting the { bracket from the same line as the while loop instead? By following the coding standards, this could help increase the readability of your code. I noticed this issue in some other lines too, for example your if-else and for loops.

I like how you used newlines to section the different parts of your code, it gives your code a more organized structure and hence enhances readability.

Perhaps you could consider assigning " " to a constant variable instead? I noticed you use this several times in your code hence naming it as a variable could enhance readability.

I like your variable names, they clearly state the use of the variable which increases your code readability!

I like the logical structure of your code, it makes it easy to follow and identify the different parts. I think that your code is clear and readable.

I like how you separated the sections in your code with a new line as the clear structure increases code readability.

I like how you stored the length of the words as constants as it makes your main code easier to read.

Should this be "tasks" instead of "tasksList" as it is representing a collection of objects?

Perhaps you could consider separating "TODO_DONE_LENGTH" to two separate constants of "TODO_LENGTH" and "DONE_LENGTH"? This may increase code readability. I noticed the similar naming style in line 8 of your code.

Perhaps you could name this as printHorizontalLine instead? This may increase your code readability since printLine may be misleading as in line 19 you named your user command as "line".

Hey since you repeat the "Alright, I've added this task..." statement for all 3 types of tasks, maybe you want to create a separate method like "printAddedTask" and print the statements from there? you can also update the value of numberOfTasks within the method as well since it is common for all 3 types of tasks:)

since the "case "todo": " and "default" have the same contents, maybe you can keep just one of them? this would make it shorter and more readable in my opinion:) but if you have different meanings for the two of them that's fine, but generally I cannot find any code violations:))

perhaps this could be in small caps? you could use camelCase convention:)

I think "LOGO" can also be in small caps:)

maybe instead of tokens you can use something like "partsOfCommand"? I think it can be more descriptive, but otherwise I see no other issues:) your code is so neat and well-written:)

maybe could be more descriptive? like "taskDone", etc.

since the "i" here means something, maybe it can be named as "index" or something more meaningful

Generally, I couldn't find much coding violations! It looks very neat:)

maybe "line" can be replaced with "dottedLine"? I was a bit confused as to what this was referring to.

maybe you could bring the catch statement to the } bracket of your try statement ( like "} catch (...) {" ) I think that is a violation that you could change:)

again here you should move the catch statement to the brackets, but otherwise I can't see any issues:)

Small Typo I think you meant getTaskIndex, not a big issue.

Similarly, the array name of Doby would be clearer if its DoBy.

i think inputParts since its an array, also I think the name might be little confusing, pershaps another clearer name would be preferred

Consistent indentation for the a long System.out statement.

spacing in between methods could be more consistent , makes the code longer than it has to be

constant terms should be named in all caps, a different name would be also preferrable

a different preferred like printBye would be better since the variable name may be confusing in the above method

a different variable name could be used instead of t, may lead to confusion further along the code

the indentation for try and catch should be

try{

} catch {

}

for indentation leave one line in between methods for shorter code

I like how you extracted the various System out print methods into a separate class

I don't think you are using this method anywhere. Perhaps it can be removed?

I like the naming of this variable; very clear what it is referring to

Perhaps you could consider adding constants to extract out the magic numbers (4 & 9)

Perhaps you could consider adding constants to extract out the magic numbers (6)

I like the naming of this boolean variable; very clear.

Great job using the plural form to represent a collection of objects

Perhaps put the else-if line on the same line as the closing bracket of the if-statement (this would follow our coding standards).

Perhaps put the else-if line on the same line as the closing bracket of the else if-statement (this would follow our coding standards).

Perhaps put the else line on the same line as the closing bracket of the else if-statement (this would follow our coding standards).

"lists" as a variable name is too general, the variable should be representing a collection of objects like "taskList"

Since this method is used throughout your code, perhaps create a method that you can call instead of repeating the code?

Naming can be more specific instead of using 't' since this variable is being used frequently

Todo, Deadline and Event classes are missing, do remember to upload their .java files!

"word" might not be appropriate as it is an input of string that may be a phrase/sentence. Maybe use "userInput"?

Missing a space between ) and {

Good to use a class file to handle all the printing of lines and commands!

Extra indentation for case not required!

"default" case is missing

As this method seems to be longer, maybe abstract the logic for each case into separate methods?

Maybe define a constant for the line?

Maybe a more intuitive method name?

Maybe define constants holding "X" or " "?

Would displayTaskList be more intuitive?

Maybe a more intuitive name for "split"?

Should the formatting indentation " " be defined as a constant?

I agree! The clear and standardised method names make it easy to follow.

As this will show the Task status and Task type as well, should descriptionCount be named more intuitively?

Perhaps you can insert a space between the '}' and "while"?

I like that you modularize your program. It definitely increases the readability.

Perhaps you might consider putting this method in another class ?

You can consider deleting the lines here.

I like how you used meaningful words to name your parameters.

Should we import the entire class? Perhaps it would be better to specify the specific class that you are going to use? I have noticed this issue in one other place as well.

What does str mean? Maybe you can rename the variable to something more meaningful?

Perhaps you can consider putting this under a new method, hello, as this might increase readability?

Perhaps you can rename part as parts since it is plural(part[0] and part[1])?

I think the main method is too long and we can maybe refactor the code to make main shorter. According to our prof, it should "tell a story"

Try to avoid deep nesting. There are many while and if conditions being nested.

I feel this line, the expression is complicated

Try to avoid magic numbers

Maybe the comment can be removed, as we are not using it in the code.

Consider removing indentations for the case clauses. (It violates coding standard)

Consider removing the logo variable can be deleted. (It is not used in the rest of the code)

Maybe it is better to remove the extra line spacings.

Good to state @Override!

the code is structured logically and sequentially, good job

consider applying SLAP principle

no deep nesting found, good job

consider using SLAP to improve the understandability of Duke.java

there might be a better variable than "by", as it might not be intuitive

can consider extracting this method as listOutTasks()

consider extracting these lines as a method

is it supposed to be "done 1"?

overall, consider applying SLAP principle, it would improve the overall readability of this code.

Good use of Camel Case naming as it's easy to identify the methods and variables

Hi, splitting the user input is a great idea!

I was thinking maybe if a more explanatory array name used to store the output will work better 😃

The aforementioned switch case formatting is done and adhered to. Great!

Hi, it's great that an object array is created.

However, I believe that magic numbers should be replaced with an appropriate name to better identify them according to the coding standards.

Hi good job on the codes.

If I remember correctly, Prof mentioned that it's better to leave an empty line at the of all the files 😃

I like how you refactor your codes to increase the readability.

The code is neat and really easy to understand.

This can be seen in other parts of your code as well.

Clear and concise comments can be found in several parts of your code.

Good job

SLAP can be seen here which is commendable.

I like how the used methods are subsequently ordered to increase the readability

I like how you had refactored the methods in this way.

Hi, I feel you can convert the commands into class-level constants.

I like it that you created a UI class. This makes the code very neat.

100 can be converted into a constant to avoid magic number.

I like how you separated the task functions in to a TaskManager class. Code is structured logically.

I have noticed from some of your methods and classes have the the space before the curly brace missing.

The if statement should have a spacing before the brackets (condition statement) like the while statement.

I noticed the same issue in several other places too.

Overall, I like that you have camelCased your method and variable names consistently.

Overall, all comments appear in the right position of your code. Good following of the standard.

I feel this can use + to connect strings to avoid multiple calls to System.out.println(), like this:

String helpString = "HELP PAGE" + NEWLINE

        + "All valid commands:" + NEWLINE + NEWLINE

        + ....

And you declared NEWLINE but you sometimes didn't use it (e.g. here)

Naming: isDeadlineOrEvent should be more appropriate as you are checking whether tokens match the pattern of deadline or event. Or alternatively, naming it as hasKeyword is also fine in my opinion.

a single line user input is processed in different functions (different levels of abstraction) REF

Declared NEWLINE but not used here.

For each function there is repeat System.out.println(BORDER);

Maybe this can be moved to before Duke.c#L189 and after Duke.c#L196, since anyway these two will be printed each time an input is received?

MAX_SIZE is a constant so you can consider mark it with final.

LIST_COUNTER is not a constant so you might want to name it using camelCase, i.e. listCounter.

I would suggest use constants or enum to represent these error codes (as they are magic numbers).

It is hard to read from code if something like error(5) is written.

The case should be on a same indentation level as switch. You might want to refer to the coding standard's The switch statement should have the following form section.

You might want to change indentation for wrapped lines to be 8 spaces. Please refer to standard's Indentation for wrapped lines should be 8 spaces section. (same applies to all wrapped lines below)

Some code duplication (here and lines 71-76), maybe these common parts can be extracted as a separate printTask() method? (DRY principle)

I think you could consider making this variable name be longer so that it can be more self-explanatory? (for example is it "at" somewhere or "at" a certain timing)

Similarly for "sc" at line 25 in Duke and "by" in Deadline perhaps!

Nice work on the clear-cut names of the methods! However the comment here is not very clear, maybe "X" and " " can be declared as constant variables of Task instead of being printed straightaway?

I like that this method is self-contained and that the logic flows nicely. Maybe the only thing would be that it is quite long, so maybe more abstraction can be done to separate the code into methods that are then called here (SLAP hard)

Maybe line wrapping could be done for long lines like this one?

I think the import statement can be more specific?

https://se-education.org/guides/conventions/java/basic.html#package-and-import-statements

I like how you concatenated these strings into a single "userQueryReturn" String object instead of doing multiple System.out.println() 😃 Only one thing is that maybe for line 21 the variable results can be broken up into intermediate ones so that what is being output looks clearer?

I think these comments could be deleted if they are no longer needed? I like to keep these code fragments too in case I need them later, but recently I have been doing it in a separate draft document instead.

Perhaps processing input could be in a separate method?

Use better boolean variable names

Use better boolean variable names e.g. if (CheckIfInteger) does sound right.

Maybe create a method within each case to make the code neater

Good implementation of wrong format for input

Firstly, i think you can have more commits to better show your updates and improve on your commit name/message

Perharps you can just create the string for the horizontal line using a method instead of a for loop to print our _ 25 times

Maybe use switch case to split up your task and use methods to handle the task required to keep the code clean

Same comment as above so as to avoid confusing nested loops and improve code clarity

Secondly, not using classes as recommended for the iP for Task, Todo, Deadline, Event etc.

I like how you made the options very clear and straightforward.

Well done in using all uppercase and underscore to separate words in constant names

I think the namings are not entirely clear, for example can the "type" be named as "classType" instead?

I like how the function is named to sound like booleans.

Would it be better if you tweak the code slightly so that you can extract methods to avoid duplicate codes?

I think the variable Task "t" should have a proper name instead of an alphabet. This is similar to the ones below too.

Should the else statement be at the same line as the curly bracket of the if statement?

I think this can be extracted out to form a method so others can have more clarity on what is going on

maybe the name split here can change to splitSentence

well indented switch case over here 😃

well indented do while loop 😃

since 'i' is the number of entry number maybe you can create a variable name "numTask" . If you are using the standard forloop the it is fine to use 'i'. Standard forloop i mean (int i; i>a; i++)

Hi !! this method is too long, it would be better if you create another class for it 😃

well indented while loop 😃

well indented if else loop 😃

This method name can be change to "printStatus" to be more descriptive 😃

I think you have put an extra indentation for all 'case'

I think it may be better to avoid complicated expressions if possible.

perhaps it may be better to use an action verb such as displayTaskAdded?

perhaps it may be better to use an action verb such as displayTaskCompleted?

It may be better to use upper case for all constants and use underscore to seperate words

I think there is an extra indentation for all 'case' within the switch statement.

I think there is an extra indentation for all 'case' in the switch statement

perhaps it is better to put )) at the previous line? I am not too sure about this actually.

It is good to use enums.

Try avoid using magic numbers

It is good to refactor these functionalities

It is good to specify overridden methods

It is a good practice to name an array as plural

It is a good practice to name a boolean variable like this.

The uppercase naming format should be used for constants only.

It is a good practice to list all imported classes explicitly

Can leave one line space between two boxes of codes!

Can delete the useless comments code

can change i to some words meaningful

Can delete this empty line

No need to leave space between these

good use of naming and Class with super

This is a very clear structure of code, I will also apply this in mine

I like the usage of a different form of lines, one:----- and one––––––––, it performs different meanings and let users easily understood.

Could modify so that it is not case-sensitive

Good to check if the list is empty before printing out the list!

could make a method to add task make code neater!

userInput.indexOf("/at")+4 could be confusing

logo and greeting could be included in one method, make code cleaner!

Good use of secondscan to retrieve next integer

a "default" for illegal input would be good

though if it's not an integer it would raise an error

maybe change a better name for task array?

Maybe it's better to try to use more methods.

Maybe make this into a method instead of printing a line every time?

It's better to make the formatting clearer.

I think it is very good to create variables for messages.

It's very good use of inheritance.

According to naming standard, perhaps better be 'description'?

Better start with a lowercase letter for integer variable?

for consistency, maybe add a blankline after case "bye" too?

Is this blank line after the close bracket of the while loop needed?

Maybe the number of blank lines at the start and end of each case can be consistent?

i like how you have included error handlings even though it has not yet been specified in the weekly project requirements

maybe this boolean variables can be named to sound more like a boolean?

is this blank line here needed?

is this an if-else-catch block? not sure if there is supposed to be a catch at the end of the if-else block

i like how you added error handling for input of the index

Avoid magic number 100

Good readability

else if is at the wrong line

wrong line for all the else if and else

Shouldn't it be "Duke"?

update taskNumber can be rewrite as a function to avoid repetition

Im sorry but you don't have to delete this right

100 is a magic number, try to change to something else

Spacings between the operators are rather inconsistent and can affect readability of the code. Try adding spaces before and after the operators.

Good that you import only the libraries that you require.

Inconsistent spacing between parentheses ( and { , as well as for the comma.

If I remember correctly from the course learning materials, if-else statements should have the form:

if (condition) {

statements;

} else {

statements;

}

Its good that you import only the necessary libraries required.

The codes does not have any deep nesting complications.

Spacings are very consistent and the method names are simple yet understandable.

No redundant methods are introduced.

Try to put these in another class

consider using switch statement?

This is good! but maybe can be part of another class like UI.class? 😃

i dont rly understand what is happening but its best not to hardcode these values 😃

nice! variation in the messages haha

consider making it case insensitive ?

try to put more methods in another class? like this printBye method can be in a UI.class maybe

consider using a switch case statement! but also i like how this should work as long as the command word is in the text!

Maybe can change to constant (final static) since logo is not expected to change

Should have spacing between the for loops conditions and operators line 38 and 48.

E.g. for (int i = 0; i > allTasks.length; i++) { ...

Might be good to create variables so it is clearer what the different parts of actionArr refer to.

Possibly rename the boolean to isDone (based on module's coding standards)

Conditional should be on separate line and should wrap single statement in curly brackets (based on module's coding standards)

The method name might be a little vague, can consider renaming the method so that it is more clear what it does.

Can consider renaming these methods as the naming does not really signify what the method does

Is the use of String.join() necessary here? Unless I'm missing something, it is possible to achieve the same result by just indexing the arguments array

Great job importing only the libraries you need!

Maybe it will be better to use a CONSTANT variable for the value 100. This would help readers understand the significance of the value 😃

Very good to create a new class for code with high reusability.

Good use of camel case, very easy to identify variables and methods.

Good use of switch case

Can avoid the magic number 100 by introducing a named constant

Good use of a constant

Methods are short and readable. Good job!

Great job separating longer lines into two lines.

I believe the conditional should be placed at a separate line and wrapped with curly brackets.

It is recommended to place a comment on top of the statement it is referring to for clarity purpose.

It is a good practice to initialize variable whenever it is declared.

Scope of a variable should be minimised. Since scanner is only used in one part of the code, it is best to make it a local variable rather than a global one.

I like the fact that you have gone ahead of the class and created javadoc for most of the methods, it lets me follow through the code easily.

You might want to implement a setDone setter method in the task class to change the isDone variable. The class level variable should be accessed and modified by setter and getter method within the class.

I think it is better to separate the conditional statements into multiple individual ones and make the main code of assigning the readFromIndex value more prominent for easier management and readability.

maybe change the getDone to isDone to match the boolean method

Consider changing the variable name to be more specific. (eg. taskCounter)

It will be nice if line spacing is consistent

good job on explaining each line for clarity

perhaps you can add "final" to say that it is a constant

Consider adding comments to explain each method

Consider adding this line into the constant list (eg. final String taskNo = " Now you have %d tasks in the list" and use string format

Perhaps you can add new methods to remove repeated lines in the code

Although its a small variable, names should be in camelCase

camelCase here too!

Methods should be written in camelCase as well

Collection of tasks should be in plural form i.e lists

Naming of boolean variable is very readable. Very good!

Good use of method overriding, allows Event class to inherit from parent Task class. Very good!

If else statements should follow proper code standards! Small issue as the other statements follow them.

Collection of tasks is in plural form! Good!

Consider removing commented parts of the code if they are not in use

Good job in having short and clear methods

Good job looks neat and clean

Overall, good job. Naming of variables and methods are self explanatory.

Good java doc comments

Consider removing parts of the code that are not in use

Good job. Clean and neat

Good use of methods. Makes the entire code readable and neat

Good work in wrapping of lines and indentation of 8 spaces

Good if-else block form. Perhaps adding spaces can help increase readability

Might be a typo due to extra space

Good explicit listing of imported classes

Code looks good. For this, I think you can use for loops to generate the line, either that or to wrap the line around as it is very lengthy

good and consistent use of camel cases

good use of classes as recommended . Well done!

Good form of if-else block

Good use of the SLAP principle

Consider splitting function in half to improve readability

Automated testing is well set up

Good use of polymorphism

Substring uses magic numbers, could try using length of the commands instead

Printing out the task can be made into a new method to avoid repetition

Good use of super and override

Good use of abstracting out the method

Looks good!

But It's better to pay attention to the code standard for the if statement. Can add one more space between the if and the left bracket before the condition.

Looks like a good subclass.

You did a good job to use inheritance to simplify the main code.

Looks good, but need to pay attention to the code standard.

It's better to add a space between the Task and [ ].

For the if-else statement, it would be better to follow the code standard requirement.

eg. Between If and left bracket to need a space and else if should inline with the "}".

Looks good!

It's better to use a simpler variable name for the startTimeMarker.

It's good to use an enum method.

You're so creative to have emotion icons in the greeting message!

It's would look better if can add a space between the double quotation mark. eg." "

I like that you have used a constant to store the Divider. You can try implementing a method to print the Divider. In that way, you will only need to call the method instead of typing System.out.println(Divider)

I like that you only used abstractions for this method. It makes it easy to read and understand.

Good job! You did not violate any coding standard.

I think you should consider using a constant to declare the array. It will improve your code quality.

It is good that you have only imported packages you need.

Good job using a constant instead of a magic number.

I like that you've used switch structure instead of nested if structure. You have avoided arrowhead!

Good job implementing your Automated Text UI Testing.

I think it might be better to name 'inputArray' as 'inputs' instead.

Good job. Clear naming of methods.

Maybe you can consider splitting this if else statements as they seem very nested.

Nice job. Clear naming of variable.

Maybe you can consider using Enum for these constants.

Good use of inheritance.

Good extraction of method.

Good use of calling methods to make things clearer.

Good job. Clean and clear naming of methods

Consider extracting out command parsing into a method on its own.

Good job. Clear naming of constant variables.

Good Job. I like how you split the print out from main.

Consider splitting out command parsing into its own method

Well done. Expression is simple and readable.

Well done. Methods are short and sweet and clear in what they do.

Well done. Name clearly explains what methods do.

Can consider putting "ToDo" in pascalCase

Can consider declaring the constant '5'. I've found the same issue in some other places as well.

Can consider refactoring "sign_off" as signOff since variable names are in camelCase.

Can consider putting printed stuff in a method.

I've noticed the same issue in other places too

Consider spelling out the whole word 'elem'

Consider spelling out the class name

can put 'todo'in PascalCase

consider a better variable name for out

consider no indentation for case clauses.

Line length try not to be longer than 120 chars.

consider better boolean variable name

nice comment that helps with better understanding of the use of variables

consider shorter name for the method

avoid deep nesting

Good comments follow through the code

Should setters for boolean variables be in the form setDone()?

Perhaps consider including @Override when overriding the toString method. This could apply for the other classes as well.

I like the use of an extracted method to print the separator!

Perhaps a clearer name for index like taskIndex would be better?

I like this wordart!

Perhaps setters for boolean variables could be in the form setDone() instead?

Clear use of if-else statements, however the switch statement may be too deeply indented and nested.

Good extracted methods to improve code clarity

Perhaps you could consider consolidating the duplicate conditional fragments? Since getStatusIcon() also checks for isDone, maybe you would not need to check for isDone within toString().

Perhaps you could consider using a plural form on names representing a collection of objects?

Maybe it is better to be explicit on which class we want when importing instead of import java.util.*?

Good use of extracting out common code into a method!

Perhaps you could consider using a plural form on names representing a collection of objects?

Perhaps you could consider using a plural form on names representing a collection of objects?

Similar to the previous naming, perhaps you could consider using a plural form on names representing a collection of objects?

I really like the use of camelCase for your variable names, but I am concerned that the name of the counter variable noOfTasks might be confusing as number was abbreviated to no. Maybe you could consider spelling number out?

Perhaps you could consider using switch statement to prevent invalid input from the user.

Good usage of inheritance and polymorphism.

Variable does sound like boolean variables!

Follow the coding standards of brackets in if else statement well.

Consider declare descriptionStart before the while loop and change the value in every condition.

Good naming for arrays.

Follows the standards of Javadoc comments.

I think case and switch statement should have same indentation

Perhaps you can logo as a constant?

Perhaps use name like line break? Since end sounds like ending the program.

Switch and case statement should have the same indentation

Perhaps you can have a task manager class to handle the tasks instead of having everything inside main?

Perhaps you can extract this if-else statement into a method?

Perhaps you can create a method for the splitting of string task and date?

Consider using switch to accomodate the possibilities

Consider using if-else statements for easier readability

Consider testing with a wider variety of test cases

Consider having a method to print this divider or having it as a constant string to print

Consider getting the indexOf the entire string instead of a single character to avoid unwanted outcomes with inputs with '/'

Good that boolean sounds like a boolean

Good comments throughout the code

Perhaps this unicode can be replaced with a more expressive constant instead, so that the comment can be removed

Instead of using the taskCount variable, is it possible to use tasks.length instead, so there is one less variable to manage?

Neat use of method overriding too for each entity

All method names are in camelCase too

Agree with the TODOs here!

Arbitrary unicode can be replaced by a more expressive constant instead

I like the use of method extraction for line breaks

Good Job in listing imported classes explicitly!

Maybe you could extract the bye message as a method?

switch-case statements are not indented, maybe you could change that?

boolean should sound like a boolean. Maybe you could change the naming?

Good job in making code readable!

Good job in using a named constant!

Maybe can rename the method to sound more like a verb?

Function name seems pretty vague, maybe you can change it to something more descriptive (e.g. interactWithUser)?

Good use of the override signature! Makes the inheritance much clearer.

Personal suggestion - Maybe these functions can be classified under "read and parse user input"?

If you frequently use the line variable (e.g. in printHello and printBye functions), you should declare it as a constant.

There are multiple nested expressions, you can consider breaking it into multiple expressions for better readability. This will also help when handling exceptions from parseInt() in the future

Maybe you can consider using 'message' instead of 'm' as the variable name (to make it more descriptive). Also, since the argument (message) is an array, you can rename it as messages so that it is clearer.

Would be good to keep the length of the comments consistent (e.g. executeAddDeadline and executeAddEvent) since they do similar actions.

I don't think this is necessary, as a blank space is guaranteed in the input.

Perhaps extracting this out into a method? I think it will make the code more readable.

Extra empty line.

I think the variable name "argument" may be unclear for readers.

This line is rather lengthy. Perhaps split into 2 separate lines?

I like the use of the extra parent class to keep track of tasks.

I like the creating of this method, makes the code much more readable.

Why is SCANNER in caps?

Use inheritance just like we learnt

Maybe use boolean variables to make this easier to understand

Using boolean variables instead of .startsWith and .equals can make things easier to understand.

Same method name as line 58, maybe use printList for this method

Line can seem overly complicated, maybe use boolean variables to make it easier to digest

Storing "bye", "todo" etc. as strings can help when you need to add more code later on

It's great that you included this part of the code to catch any invalid input

You can also consider testing with corner cases, such as null or try inputs that don't fit your command format

overall the code adheres to the coding guidelines, but there are some minor changes that can be made to improve on code readability, as suggested by the other reviewer.

It's nice that all the values used are well-explained. Constants are also in uppercase and readable.

Would be better if the spacings for brackets and parenthesis are more consistent. Can consider using the auto-formatting function for code style in your ide

Great that there is a variety of test cases used, including invalid commands and syntax

Inconsistent spacings for space between parenthesis and brackets

Running boolean should be isRunning so it looks like a boolean

public Event(String content) {

public Todo (String name) {

can use verb as the name of the function, "outputReaction" does not sound very clear

good coding standard to limit one line long size

good coding standard for switch statement

You can consider using "final" to indicate that the value is constant.

Great job on writing a multi-line command as it looks neat!

It would be better to name your classes in capital.

You can consider adding a space after symbols such as '+', ',', etc.

It would be nice to remove one empty line here so it would be consistent

Since you're naming the other classes as 'Events', 'Deadlines', and 'Todos', might be nice to change this to 'Tasks' as well.

Yeah is this a leftover from some debugging you were doing? please remove

Good of you to comment this so that readers can know what the unicode symbols are

Nice comment. Mentioning possible bugs for reviewers is great

Why not use a switch statement like the above method? It is cleaner than nested if-else.

Coding standard violation: else if should be on the same line as the closing bracket of the previous if block.

Nested for-loops might not be efficient.

Good use of capital letter for constants

can be more efficient through taking out common codes for each if-else statement

Simple and clean

good coding quality

i suggest to use Plural form for your variable

maybe can name "listTasks" instead

maybe can add these lines into your deadline class (:

good use of case statements! very little nesting, good job (:

to improve readability, i suggest to have a section divider variable for this! (:

Cool usage of TaskManager class to handle Tasks. However, the naming of the variable might be too similar with the array of tasks within the class.

Nice usage of enum!

Do take note of the formatting of the if-else block to meet the coding standards.

Looks good but do consider removing the curly braces.

In using K&R style brackets, take note of the spacing of the initial curly braces. Do ensure they are consistent throughout for all opening curly braces.

Since the Duke logo is unlikely to change while in use, would it perhaps be better to declare this as a constant?

Since the Duke logo is unlikely to change while in use, would it perhaps be better to declare it as a constant instead?

If I recall correctly, if-else statements should have the form

if (condition) {

    statements;

} else {

    statements;

}

Perhaps you could review the java coding standard again?

The formatting here is a little inconsistent (no space between ) and { )

I like how clearly your comments explain your code!

Perhaps K&R egyptian style brackets should be useed?

I like how you used camelCase for variable names

I like the usage of camelCase for variables

I like the usage of k&r style brackets

I think there's a typo here. There should be a space between the class name and the opening brace.

It might be better to have spaces between the conditional statement and opening braces.

I think it would be better to name the array after the type of object it contains. (eg. naming the array "Tasks" instead of "list")

Might be better to extract a method out for this? Same for line 89 (eg. printNoTime() )

Excellent use of Try and Catch.

Could use more OOP

Use a switch statement instead of a if and else statement

better to name "isDone"

Good naming standard

switch variable not indiciate much info.

Maybe can rename the function so that it gives more insight to what the function does

Good use of object-oriented programming concepts! Overall code was well written and clear.

Maybe can list the imported classes explicitly

I think that maybe the main function can be more logically structured.

if it is possible, varying the level of abstraction within a code fragment should be avoided.

i think maybe the name of the function can be changed to toString(), which inherited from the Object class that is used by Java to get a string representation of the object. it will be called automatically by System.out.println()

I like the classes you defined and their inherent.

maybe the code can be seperated into several class files.

I think that for if else statement, we are supposed to flush the else after the if statement closing bracket }. For example,

if (condition) {

statements;

} else {

statements;

}

Good to standardize having a space between ) and {

Maybe can use constants instead of magic numbers

clear indentation good format

clear structure easy to read

clear if else format

What you can do here is }else{ in 1 line if you really want to follow the coding standard

Easy to understand what this function does by the function name. Good use of the naming. I think to improve on the naming and readability further, the parameter t can be renamed to maybe newTask. This can be easily understood that the function storeTask is storing the newly created task into a certain position on the tasks array. Lastly, you will be using newTask.description instead of t.description.

Agree with the good use of lineBreak() on method extraction! Perhaps can create a class for all the miscellaneous output like this.

Perhaps change "taskList" to "tasks" (plural form) as it is representing a collection of objects.

Can remove comments that are unrelated to the task

I like the use of Override for methods, as they seem to be used appropriately. (I have noticed this for several other methods as well)