-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Nguyen Hoang Hai Minh] iP #445
base: master
Are you sure you want to change the base?
Conversation
* branch-Level-8: level 8 added # Conflicts: # src/main/java/Duke.java
A-MoreOOP added
* branch-Level-9: Level-9 Added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I like how your code is concise, readable and very easy to understand for the most parts. Most method and class names are clear and correctly adhered to coding standards. However, it is worth noting that there are a few minor coding standard violations and missing JavaDoc header comments for several classes and methods.
It looks good to merge. Keep up the good work 👍
src/main/java/Deadline.java
Outdated
String description; | ||
String deadline; | ||
boolean isDone; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
src/main/java/Deadline.java
Outdated
/** | ||
* Status in format [D][x] return book (by: 6 June) | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/Duke.java
Outdated
@@ -1,10 +1,152 @@ | |||
//package duke; | |||
import java.io.IOException; | |||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps you could list out all the imported classes explicitly? I noticed the same issue in several other classes as well.
src/main/java/Duke.java
Outdated
private Storage storage; | ||
private TaskList tasks; | ||
private Ui ui; | ||
private Parser parser; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps you could consider adding JavaDoc comments for class members as well?
src/main/java/Duke.java
Outdated
public void run() { | ||
ui.sayHi(); | ||
Scanner myScanner = new Scanner(System.in); | ||
while(true) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/Storage.java
Outdated
myReader.close(); | ||
} | ||
} catch (FileNotFoundException e) { | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/TaskList.java
Outdated
return tasks.size(); | ||
} | ||
|
||
public Task get(int i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/TaskList.java
Outdated
tasks.add(tmp); | ||
} | ||
|
||
public TaskList(ArrayList<Task> tasks) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/test/java/TaskListTest.java
Outdated
|
||
public class TaskListTest { | ||
@Test | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/Deadline.java
Outdated
/** | ||
* Deadline <- Task | ||
*/ | ||
public class Deadline extends Task { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how all the class names in your code and clear, concise and adhered to the Java coding standards and naming conventions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I feel like there are generally no major improvements needed to your coding quality as it is very comprehensive and readable. I also appreciate that you generally did not recycle variables or parameters and avoided empty catch blocks. However, I do feel like certain dead codes could have been omitted although it does not affect the readability of your code.
It has been a pleasant read and I love the simplicity in your coding style! I think it is good to go for merging.
src/main/java/Deadline.java
Outdated
/** | ||
* Deadline <- Task | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/Duke.java
Outdated
ui = new Ui(); | ||
storage = new Storage(); | ||
tasks = new TaskList(storage.readData()); | ||
parser = new Parser(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like 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.
src/main/java/Duke.java
Outdated
System.out.println(i + "." + tasks.get(i - 1).getStatus()); | ||
} | ||
} | ||
else if(cmd.length() >= 4 && cmd.substring(0, 4).equals("done")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
src/main/java/Duke.java
Outdated
checkCmd(cmd, 8, "☹ OOPS!!! The description of a deadline cannot be empty."); | ||
String getName = parser.getNameBy(cmd); | ||
String getDeadline = parser.getDeadlineBy(cmd); | ||
getDeadline = formatDate(getDeadline); | ||
Deadline tmp = new Deadline(getName, getDeadline); | ||
System.out.println("Got it. I've added this task: "); | ||
System.out.println(" " + tmp.getStatus()); | ||
tasks.add(tmp); | ||
System.out.println("Now you have " + tasks.getSize() + " tasks in the list."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I 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?
src/main/java/Parser.java
Outdated
/** | ||
* translate command -> name and time | ||
*/ | ||
public class Parser { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I 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.
src/test/java/TodoTest.java
Outdated
Todo todo = new Todo("test"); | ||
assert(todo.getType() == "T"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like how you did testing of the lowest complexities as it shows that you place focus on the minute details of your code!
…000/ip into A-Gradle * 'add-gradle-support' of https://github.com/minhhhnguyen2000/ip: Add Gradle support # Conflicts: # gradle/wrapper/gradle-wrapper.jar # gradle/wrapper/gradle-wrapper.properties # gradlew # gradlew.bat
* master: Add Stream Collectors
No description provided.