Skip to content
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

Open
wants to merge 71 commits into
base: master
Choose a base branch
from
Open

[Nguyen Hoang Hai Minh] iP #445

wants to merge 71 commits into from

Conversation

nevirmc
Copy link

@nevirmc nevirmc commented Aug 27, 2020

No description provided.

Copy link

@jonasngs jonasngs left a 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 👍

Comment on lines 6 to 8
String description;
String deadline;
boolean isDone;

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?

Comment on lines 18 to 20
/**
* Status in format [D][x] return book (by: 6 June)
*/
Copy link

@jonasngs jonasngs Aug 31, 2020

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.

@@ -1,10 +1,152 @@
//package duke;
import java.io.IOException;
import java.util.*;
Copy link

@jonasngs jonasngs Aug 31, 2020

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.

Comment on lines 14 to 17
private Storage storage;
private TaskList tasks;
private Ui ui;
private Parser parser;

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?

public void run() {
ui.sayHi();
Scanner myScanner = new Scanner(System.in);
while(true) {
Copy link

@jonasngs jonasngs Aug 31, 2020

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.

myReader.close();
}
} catch (FileNotFoundException e) {
}

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.

return tasks.size();
}

public Task get(int i) {
Copy link

@jonasngs jonasngs Aug 31, 2020

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.

tasks.add(tmp);
}

public TaskList(ArrayList<Task> tasks) {

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.


public class TaskListTest {
@Test

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.

/**
* Deadline <- Task
*/
public class Deadline extends Task {

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.

Copy link

@Syasyazman Syasyazman left a 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.

Comment on lines 2 to 4
/**
* Deadline <- Task
*/

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.

Comment on lines 23 to 26
ui = new Ui();
storage = new Storage();
tasks = new TaskList(storage.readData());
parser = new Parser();

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.

System.out.println(i + "." + tasks.get(i - 1).getStatus());
}
}
else if(cmd.length() >= 4 && cmd.substring(0, 4).equals("done")) {

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!

Comment on lines 79 to 87
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.");

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?

/**
* translate command -> name and time
*/
public class Parser {

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.

Comment on lines 10 to 11
Todo todo = new Todo("test");
assert(todo.getType() == "T");

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants