anonymxtrix / ip Goto Github PK

Implement a skeletal version of Duke that starts by greeting the user, simply echos commands entered by the user, and exits when the user types bye.

Example:

    ____________________________________________________________
     Hello! I'm Duke
     What can I do for you?
    ____________________________________________________________

list
    ____________________________________________________________
     list
    ____________________________________________________________

blah
    ____________________________________________________________
     blah
    ____________________________________________________________

bye
    ____________________________________________________________
     Bye. Hope to see you again soon!
    ____________________________________________________________

• The indentation and horizontal lines are optional.

Add support for deleting tasks from the list.

Example:

list
    ____________________________________________________________
     Here are the tasks in your list:
     1.[T][X] read book
     2.[D][X] return book (by: June 6th)
     3.[E][ ] project meeting (at: Aug 6th 2-4pm)
     4.[T][X] join sports club
     5.[T][ ] borrow book
    ____________________________________________________________

delete 3
    ____________________________________________________________
     Noted. I've removed this task: 
       [E][ ] project meeting (at: Aug 6th 2-4pm)
     Now you have 4 tasks in the list.
    ____________________________________________________________

Refactor the code to extract out closely related code as classes.

Minimal: Extract the following classes:

• Ui: deals with interactions with the user
• Storage: deals with loading tasks from the file and saving tasks in the file
• Parser: deals with making sense of the user command
• TaskList: contains the task list e.g., it has operations to add/delete tasks in the list

Add the ability to mark tasks as done.

list
    ____________________________________________________________
     Here are the tasks in your list:
     1.[X] read book
     2.[ ] return book
     3.[ ] buy bread
    ____________________________________________________________

done 2
    ____________________________________________________________
     Nice! I've marked this task as done: 
       [X] return book
    ____________________________________________________________

While it is possible to represent a task list as a multi-dimensional array containing primitive values, the more natural approach is to use a Task class to represent tasks.

public class Task {
    protected String description;
    protected boolean isDone;

    public Task(String description) {
        this.description = description;
        this.isDone = false;
    }

    public String getStatusIcon() {
        return (isDone ? "X" : " "); // mark done task with X
    }

    //...
}

Task t = new Task("read book");
t.markAsDone();

Teach Duke to deal with errors such as incorrect inputs entered by the user.

Example:

todo
    ____________________________________________________________
     ☹ OOPS!!! The description of a todo cannot be empty.
    ____________________________________________________________

blah
    ____________________________________________________________
     ☹ OOPS!!! I'm sorry, but I don't know what that means :-(
    ____________________________________________________________

Use exceptions to handle errors. For example, define a class DukeException to represent exceptions specific to Duke.

• Minimal: handle at least the two types of errors shown in the example above.
• Stretch goal: handle all possible errors in the current version. As you evolve Duke, continue to handle errors related to the new features added.

Add JUnit tests to test the behavior of the code.

Requirements:

• Minimum: More than two test methods, preferably targeting more than one class (if you have multiple classes)

Give users a way to find a task by searching for a keyword.

Example:

find book
    ____________________________________________________________
     Here are the matching tasks in your list:
     1.[T][X] read book
     2.[D][X] return book (by: June 6th)
    ____________________________________________________________

Add support for tracking three types of tasks:

1. ToDos: tasks without any date/time attached to it e.g., visit new theme park
2. Deadlines: tasks that need to be done before a specific date/time e.g., submit report by 11/10/2019 5pm
3. Events: tasks that start at a specific time and ends at a specific time e.g., team project meeting on 2/10/2019 2-4pm

Example:

todo borrow book
    ____________________________________________________________
     Got it. I've added this task: 
       [T][ ] borrow book
     Now you have 5 tasks in the list.
    ____________________________________________________________

list
    ____________________________________________________________
     Here are the tasks in your list:
     1.[T][X] read book
     2.[D][ ] return book (by: June 6th)
     3.[E][ ] project meeting (at: Aug 6th 2-4pm)
     4.[T][X] join sports club
     5.[T][ ] borrow book
    ____________________________________________________________

deadline return book /by Sunday
    ____________________________________________________________
     Got it. I've added this task: 
       [D][ ] return book (by: Sunday)
     Now you have 6 tasks in the list.
    ____________________________________________________________

event project meeting /at Mon 2-4pm
    ____________________________________________________________
     Got it. I've added this task: 
       [E][ ] project meeting (at: Mon 2-4pm)
     Now you have 7 tasks in the list.
    ____________________________________________________________

At this point, dates/times can be treated as strings; there is no need to convert them to actual dates/times.

Example:

deadline do homework /by no idea :-p
    ____________________________________________________________
     Got it. I've added this task: 
       [D][ ] do homework (by: no idea :-p)
     Now you have 6 tasks in the list.
    ____________________________________________________________

As there are multiple types of tasks that have some similarity between them, you can implement classes Todo, Deadline and Event classes to inherit from a Task class.

Furthermore, use polymorphism to store all tasks in a data structure containing Task objects e.g., Task[100].

public class Deadline extends Task {

    protected String by;

    public Deadline(String description, String by) {
        super(description);
        this.by = by;
    }

    @Override
    public String toString() {
        return "[D]" + super.toString() + " (by: " + by + ")";
    }
}

Task[] tasks = new Task[100];
task[0] = new Deadline("return book", "Monday");

Tweak the code to comply with a given coding standard. From this point onward, ensure any new code added are compliant with the given coding standard.

Organize the classes into suitable java packages.

• Minimal: put all classes in one package e.g., duke
• Stretch goal: divide into multiple packages as the number of classes increase e.g., duke.task, duke.command

We did an automated analysis of your code to detect potential areas to improve the code quality. We are sharing the results below, to help you improve the code further.

IMPORTANT: Note that the script looked for just a few easy-to-detect problems only, and at-most three example are given i.e., there can be other areas/places to improve.

Aspect: Tab Usage

No easy-to-detect issues 👍

Aspect: Naming boolean variables/methods

No easy-to-detect issues 👍

Aspect: Brace Style

No easy-to-detect issues 👍

Aspect: Package Name Style

No easy-to-detect issues 👍

Aspect: Class Name Style

No easy-to-detect issues 👍

Aspect: Dead Code

No easy-to-detect issues 👍

Aspect: Method Length

No easy-to-detect issues 👍

Aspect: Header Comments

Example from src/main/java/duke/exception/UserException.java lines 11-14:

    /**
     * Create a duke.exception.UserException with the specified Message.
     * @param message The message to be displayed in the duke.Response.
     */

Example from src/main/java/duke/task/TaskCollection.java lines 64-68:

    /**
     * Parse a String of Tasks into a List.
     * @param string The input String of Tasks
     * @return The List of Tasks
     */

Example from src/main/java/duke/task/TaskCollection.java lines 101-104:

    /**
     * Get the number of Tasks in the duke.task.TaskCollection.
     * @return The size of the duke.task.TaskCollection.
     */

Suggestion: Ensure method/class header comments follow the format specified in the coding standard, in particular, the phrasing of the overview statement

Aspect: Recent Git Commit Message (Subject Only)

possible problems in commit 0203b0e:

Merge remote-tracking branch 'origin/add-gradle-support' into branch-A-Gradle

• Longer than 72 characters

Suggestion: Follow the given conventions for Git commit messages

ℹ️ The bot account @cs2103-bot used to post this issue is un-manned. Do not reply to this post (as those replies will not be read). Instead, contact [email protected] if you want to follow up on this post.

Add the ability to store whatever text entered by the user and display them back to the user when requested.

Example:

    ____________________________________________________________
     Hello! I'm Duke
     What can I do for you?
    ____________________________________________________________

read book
    ____________________________________________________________
     added: read book
    ____________________________________________________________

return book
    ____________________________________________________________
     added: return book
    ____________________________________________________________

list
    ____________________________________________________________
     1. read book
     2. return book
    ____________________________________________________________
bye
    ____________________________________________________________
     Bye. Hope to see you again soon!
    ____________________________________________________________

• There is no need to save the data to the hard disk.
• Assume there will be no more than 100 tasks. If you wish, you may use a fixed size array (e.g., String[100]) to store the items.

Save the tasks in the hard disk automatically whenever the task list changes. Load the data from the hard disk when Duke starts up. You may hard-code the file name and location eg. [project_root]/data/duke.txt

The format of the file is up to you. Example:

T | 1 | read book
D | 0 | return book | June 6th
E | 0 | project meeting | Aug 6th 2-4pm
T | 1 | join sports club

If you use file paths in your code,

• remember to use relative paths rather than absolute paths such as C:\data. If not, your app can cause unpredictable results when used in another computer.
• remember to specify file paths in an OS-independent way. If not, your app might not work when used on a different OS.

Your code must handle the case where the data file doesn't exist at the start. Reason: when someone else takes your Duke and runs it for the first time, the required file might not exist in their computer. Similarly, if you expect the data file to be in as specific folder (eg. ./data/), you must also handle the folder-does-not-exist-yet case.

Teach Duke how to understand dates and times. For example, if the command is deadline return book /by 2/12/2019 1800, Duke should understand 2/12/2019 1800 as 2nd of December 2019, 6pm, instead of treating it as just a String.

• Minimal: Store deadline dates as a java.time.LocalDate in your task objects. Accept dates in a format such as yyyy-mm-dd format (e.g., 2019-10-15) and print in a different format such as MMM dd yyyy e.g., (Oct 15 2019).
• Stretch goal: Use dates and times in more meaningful ways. e.g., add a command to print deadlines/events occurring on a specific date.

A code snippet using the LocalDate class:

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.time.temporal.ChronoUnit;

public class Main {
    public static void main(String[] args) {
        //create dates from strings
        LocalDate d1 = LocalDate.parse("2019-12-01");
        LocalDate d2 = LocalDate.parse("2019-12-02");
        LocalDate d3 = LocalDate.parse("2019-12-02");
        
        //compare dates
        System.out.println(d1.isBefore(d2)); // -> true
        System.out.println(d1.isAfter(d2)); // -> false
        System.out.println(d2.equals(d3)); // -> true
        
        //work with dates
        System.out.println(d1.getDayOfWeek()); // -> SUNDAY
        System.out.println(d1.getMonth()); // -> DECEMBER
        System.out.println(d1.plus(1, ChronoUnit.YEARS));  // -> 2020-12-01
        
        // get today's date and print it in a specific format
        LocalDate d4 = LocalDate.now();
        System.out.println(d4); // -> 2019-10-15
        System.out.println(d4.format(DateTimeFormatter.ofPattern("MMM d yyyy"))); // -> Oct 15 2019
    }
}

We did an automated analysis of your code to detect potential areas to improve the code quality. We are sharing the results below, so that you can avoid similar problems in your tP code (which will be graded more strictly for code quality).

IMPORTANT: Note that the script looked for just a few easy-to-detect problems only, and at-most three example are given i.e., there can be other areas/places to improve.

Aspect: Tab Usage

No easy-to-detect issues 👍

Aspect: Naming boolean variables/methods

No easy-to-detect issues 👍

Aspect: Brace Style

No easy-to-detect issues 👍

Aspect: Package Name Style

No easy-to-detect issues 👍

Aspect: Class Name Style

No easy-to-detect issues 👍

Aspect: Dead Code

No easy-to-detect issues 👍

Aspect: Method Length

No easy-to-detect issues 👍

Aspect: Class size

No easy-to-detect issues 👍

Aspect: Header Comments

Example from src/main/java/duke/exception/UserException.java lines 11-14:

    /**
     * Create a UserException with the specified Message.
     * @param message The message to be displayed in the Response.
     */

Example from src/main/java/duke/exception/UserException.java lines 19-22:

    /**
     * Create a UserException with the specified Message array.
     * @param messages The messages to be displayed in the Response.
     */

Suggestion: Ensure method/class header comments follow the format specified in the coding standard, in particular, the phrasing of the overview statement

Aspect: Recent Git Commit Message (Subject Only)

No easy-to-detect issues 👍

❗ You are not required to (but you are welcome to) fix the above problems in your iP, unless you have been separately asked to resubmit the iP due to code quality issues.

ℹ️ The bot account @nus-se-bot used to post this issue is un-manned. Do not reply to this post (as those replies will not be read). Instead, contact [email protected] if you want to follow up on this post.

Use the input/output redirection technique to semi-automate the testing of Duke.

Notes:

• A tutorial of this technique is here.
• The required scripts are provided in the Duke repo (see the text-ui-test folder).