trxe / ip Goto Github PK

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

Example from src/main/java/duke/tasks/Task.java lines 9-9:

    protected boolean done;

Suggestion: Follow the given naming convention for boolean variables/methods (e.g., use a boolean-soundingprefix).You may ignore the above if you think the name already follows the convention (the script can report false positives in some cases)

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

No easy-to-detect issues 👍

Aspect: Recent Git Commit Message (Subject Only)

possible problems in commit 62629e4:

Release

• Perhaps too short (?)

possible problems in commit 671b389:

Release

• Perhaps too short (?)

possible problems in commit f62098c:

Release

• Perhaps too short (?)

Suggestion: Follow the given conventions for Git commit messages for future commits (no need to modify past commit messages).

❗ 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.

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

Example from src/main/java/duke/Ui.java lines 64-64:

            boolean found = false;

Example from src/main/java/duke/tasks/Task.java lines 9-9:

    protected boolean done;

Example from src/main/java/duke/utils/Record.java lines 5-5:

    private final boolean terminate;

Suggestion: Follow the given naming convention for boolean variables/methods

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

Example from src/main/java/duke/Storage.java lines 26-26:

            // String filename = Main.class.getResource("bin/duke.txt").getPath();

Example from src/main/java/duke/tasks/Deadline.java lines 63-63:

        // return String.format("D | %d | %s | %s", super.done ? 1 : 0, super.desc, dl);

Example from src/main/java/duke/tasks/Event.java lines 71-71:

        // return String.format("E | %d | %s | %s", super.done ? 1 : 0, super.desc, time);

Suggestion: Remove dead code from the codebase.

Aspect: Method Length

No easy-to-detect issues 👍

Aspect: Header Comments

Example from src/main/java/duke/utils/DukeDateTime.java lines 80-84:

    /**
     * Default formatting of this DukeDateTime.
     *
     * @return String formatting of this DukeDateTime.
     */

Example from src/main/java/duke/utils/DukeDateTime.java lines 90-95:

    /**
     * Formatting of this DukeDateTime according to f.
     *
     * @param f Format desired.
     * @return String formatting of this DukeDateTime.
     */

Example from src/main/java/duke/utils/DukeDateTime.java lines 109-116:

    /**
     * Formatting of this DukeDateTime according to f1, f2.
     * Separated by a single blank space.
     *
     * @param f1 Format desired.
     * @param f2 Format desired.
     * @return String formatting of this DukeDateTime.
     */

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 👍

ℹ️ 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.