Using -n prefixes makes it quite hard to separate from the parameters

[tanjiaxian99]

When I enter a command, it is quite hard to see where the prefixes end and where the parameters begin. For instance, -nnougat, or -llist. Command such as -ti1 is extremely hard to read as well. Having a delimiter such a "/" or ";" would make it easier for the users to differentiate prefixes and parameters.

Another result of this issue is that testing can be quite difficult, especially when there are a lot of parameters and prefixes, like the edit command.

[nus-pe-bot]

Team's Response

First off, we use flags such as -n, -l as we are catering our product to a target audience who are decent/proficient at using Linux CLIs.

Linux CLIs also uses a similar flag style.

Furthermore, users can add a whitespace between the flag and the parameter if they wish to distinguish them more clearly. For e.g., -n nougat. Trailing whitespaces front or back are not considered as part of the parameter.

Also, it is not hard to test the feature since at least a white space is required to separate the [flag][parameters].

Take the command add -n john -p 8333112 -e email@example.com -a street 21 as an example:

• -n john, -p 8333112, -e email@example.com and -a street 21 are/must be separated by at least one whitespace, hence it is no more different than using delimiters such as "/" or ";". We simply modified the AB3 parser to look out for -[flag] formats instead of the original [flag]/ formats.

If you are talking about the edit command, specifically the edit task portion.

Take the command edit 1 -ti2 -tnEat lunch -tt11:59 -td2021-10-21 -nJames as an example:

• During the initial parsing, -tn -tt -td which are all flags relating to the attribute of tasks are not detected as valid flags. Any character except valid flags(e.g., -n, -p) would be taken as part of the parameter after the -ti flag. Hence 2 -tnEat lunch -tt11:59 -td2021-10-21 is considered a parameter which would be handled/parsed separately. The 2 would be extracted as the task index, while parameters of -tn, tt and td are extracted as values to replace the old ones. Therefore, despite the command looking very complex to implement, it is actually handled in a simple manner by the backend code, making it NOT HARD to test.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: My issue is not with the flag style, but rather the difficulty of distinguishing between the flag and the parameter. From my reading of the UG during the testing phase, I did not once recall the ability to add whitespaces between the flag and the parameter. In the command format and the examples given, there are no whitespaces between the flags and the parameters. The only instance where this was explicitly mentioned was for commands which require a definite whitespace between the flag and parameter, such as find. As the use of whitespaces was not pointed out in the UG, I do not see how users are expected to know of this feature, in which case this continue to stand as a feature flaw.

With regards to testability, my point is not so much of testing by the developer's side, by from my own testing experience. As it stands, the edit command can take in 8 flags and parameters. Without the possibility of introducing whitespace, I had a hard time trying to decipher which flag I have used and whether I have used it correctly. If I had to lean in on my monitor multiple times during the testing phase to check if my command format is correct, I can only imagine the unpleasantness that normal users have to go through when using this app frequently.

Going by the assumption that whitespaces cannot be introduced between a flag and a parameter, this is a medium severity bug that affects all users when they type any command which requires flags.

---