Skip to content

[Xiangcheng] iP#616

Open
Xczheng0105 wants to merge 67 commits intonus-cs2103-AY2425S1:masterfrom
Xczheng0105:master
Open

[Xiangcheng] iP#616
Xczheng0105 wants to merge 67 commits intonus-cs2103-AY2425S1:masterfrom
Xczheng0105:master

Conversation

@Xczheng0105
Copy link

@Xczheng0105 Xczheng0105 commented Sep 1, 2024

Trackie

“You don’t need a new plan for next year. You need a commitment TRACKIE BOT RIGHT NOW.” – Seth Godin(modified)

Trackie is a bot to help you track your tasks.

  • simple
  • effective
  • reliable

(And did I forget to mention, it's FREE!)

All you need to do is:

  1. Launch the bot
  2. Add you tasks
  3. Let it track 'em all 😎

If you are a Java programmer, you can use it to practice Java too. Here's the main method:

public static void main(String[] args) {
        new Trackie("src").run();
    }

Features:

  • Add tasks
  • Remove tasks
  • Mark/unmark tasks
  • GUI interface (Work in Progress)
If you can type fast
Then this is the right task tracker for you!

damithc and others added 22 commits July 11, 2024 16:52
In build.gradle, the dependencies on distZip and/or distTar causes
the shadowJar task to generate a second JAR file for which the
mainClass.set("seedu.duke.Duke") does not take effect.
Hence, this additional JAR file cannot be run.
For this product, there is no need to generate a second JAR file
to begin with.

Let's remove this dependency from the build.gradle to prevent the
shadowJar task from generating the extra JAR file.
* branch-Level-7:
  Fix some bugs related to loading of tasks on startup
  Re-implement functionality for saving tasks
  Add support for reading and writing to a data file
* branch-level-8:
  Change the way of storing deadlines
* branch-A-moreOOP:
  Add more OOP
* branch-A-Packages:
  Sort the classes into packages
* add-gradle-support:
  build.gradle: Prevent generating a second JAR file
  Bump gradle and lib version
  Add Gradle support
@Override
public void execute(TaskList tasklist, Ui ui, Storage storage) {
try {
switch (arguments[0]) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not have indentation for case clauses.

return new ListCommand();
case "bye":
return new ExitCommand();
default:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of default to catch invalid commands

@@ -0,0 +1,32 @@
package trackie.commands;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good adherence to package and import statements orderings

public class Parser {
public static Command parseCommand(String input) {
String[] arguments = input.split(" ");
switch (arguments[0]) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise, case clauses should not be indented

import trackie.storage.Storage;
import trackie.storage.TaskList;

public class Trackie {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can consider adding javadoc comments to your classes for clarity

@@ -0,0 +1,32 @@
package trackie.commands;

import trackie.storage.Storage;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good adherence to explicitly import specific classes

Copy link

@maertan maertan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job on overall code quality! Here are some suggestions in the comments below:

import trackie.ui.Ui;

public abstract class Command {
protected String[] arguments;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good naming of arguments as plural due to it being an array.

this.isExit = isExit;
}

public boolean isExit() {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good naming of the boolean - starts with "is".

@@ -0,0 +1,27 @@
package trackie.parsing;

import trackie.commands.*;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps you should have explicit import statements rather than using *


public class Storage {
private TaskList taskList;
private File fPtr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps fPtr could be written out as a full word, filePointer I'm guessing? So that it would be easier for other people reading your code to understand.

throw new TrackieException("Correct usage: event [desc] /from [start] /to [end]");
}
//retrieve the start time
StringBuilder sb2 = new StringBuilder();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps you could use another way of naming to distinguish the StringBuilders rather than using numbers.


public abstract class Task {
protected String description;
protected boolean completed;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could consider naming this boolean something like isCompleted so that it sounds like a boolean.

Xczheng0105 and others added 30 commits September 14, 2024 00:24
* branch-Level-10:
  Delete the Ui class (did not manage to delete properly beforehand)
Some methods in the code are over 100 lines long.

This may hinder code readability.

Let's refactor the code and extract some smaller methods from the
long method.

This will make the code more readable.
Start and end times are stored as strings in an event task.

This can lead to nonsensical inputs.

Let's change the type of start and end time to a LocalDateTime.

This way, start and end times will not contain blatantly
nonsensical inputs.
# Conflicts:
#	src/main/java/trackie/commands/AddCommand.java
For event classes, the default date and time syntax to follow is
quite awkward and complicated.

This can result in a bad user experience.

Let's change the date and time syntax to something that is more
user-friendly.

This way, dates and times will be presented in a more user-readable
format.
# Conflicts:
#	src/main/java/trackie/commands/InvalidCommand.java
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.

5 participants