Module code is "/mod" for list command but "/code" for edit command

[Bisceto]

Both "/mod" for list command and "/code" for edit command are both referring to the module code e.g CS2040S, so the parameters should be standardised across commands. This can cause inconvenience for the user, as they have to remember two different parameters for the same field, or get the error message before correcting their command.

[nus-se-bot]

Team's Response

Our reason for having a /code argument for the edit command is 2 folds. To explain our reasoning, it would be useful if you can refer to the edit command format for editing a module and the edit command format for editing a lecture.

For reference

The edit command format for editing a module is as follows:

edit {module_code} [/code {updated_code}] [/name {updated_name}] [/tags {tag_1}[, {tag_2}[, ...]]]

The edit command format for editing a lecture is as follows:

edit {lecture_name} /mod {module_code} [/name {updated_name}] [/tags {tag_1}[, {tag_2}[, ...]]]

Reason 1

Suppose we replace /code with /mod, the edit command format for editing a module would now be:

edit {module_code} [/mod {updated_code}] [/name {updated_name}] [/tags {tag_1}[, {tag_2}[, ...]]]

It would then be possible for the edit command to encounter certain ambiguous situations. For example,

edit W1 /mod CS2040S /name New Name

This command can now be interpreted as:

1. The user wants to edit the module with module code "W1" to have an updated module code "CS2040S" and an updated name "New Name".

2. The user wants to edit a lecture named "W1" in a module with code "CS2040S" such that the lecture will have an updated name "New Name".

We are now unable to discern the intent of the user. Hence, changing /code to /mod does not work.

Reason 2

The /mod and /code arguments have different purposes. The /mod argument is generally use by many commands to specify the code of a module that a lecture is in, such as when adding a lecture, or when editing the details of a lecture. The /code argument is unique to the edit command and serves the purpose of specifying the updated module code. Since we have 2 very different purposes, we feel that it is clearer for the user if the 2 arguments are kept separate so as to help the user associate specific purposes with specific arguments. We feel that this is especially important in our case as we have many commands that use the same arguments for the same purpose.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---