Didn't handle for invalid format

[nus-se-script]

if there are no space between address and t\friends, this product will consider t\friend will be part of the address, but apparently its not, this product should check whether if tag is exist or not or sth

---

_{[original: nus-cs2103-AY2425S1/pe-interim#468] [original labels: severity.Low type.FunctionalityBug]}

[appleshill]

Team's Response

As per the CS2103T website, one can observe that deliberate sabotage is not considered to be a functionality bug. More specifically,

such mistakes should not crash the app, corrupt the data, or make it unusable

The application does not become unusable, the data is still correctly stored as the user input it, and the application does not crash.

Furthermore, the command templates provided should the user click on the GUI buttons already includes the space, as do all mentions of relevant commands in the UG and all example commands provided in the UG, in the help menu of the application, in the manual testing instructions in the DG and the error messages for those commands in the application.

Additionally, the constraint of tP is mentioned on the CS2103T site to be:

Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via a command line interface (CLI), compared to a hypothetical GUI-only version of the app

So it would be reasonable to assume that this application should be following the standards of a command-line application. And in many widely used and acclaimed command line systems, including but not-limited to Linux, Unix, POSiX and other similar systems, along with their respective command shells such as but not limited to ZSH, Bash or even Windows Powershell/Command Prompt, it is widely accepted that whitespaces are used as a delimiter between command arguments. For example, in the following document:

POSIX.1-2024 is simultaneously IEEE Std 1003.1™-2024 and The Open Group Standard Base Specifications, Issue 8, Section 12.1

available from https://pubs.opengroup.org/onlinepubs/9799919799/ One can see the following excerpt:

Option-arguments are shown separated from their options by characters, except when the option-argument is enclosed in the '[' and ']' notation to indicate that it is optional. This reflects the situation in which an optional option-argument (if present) is included within the same argument string as the option; for a mandatory option-argument, it is the next argument. The Utility Syntax Guidelines in 12.2 Utility Syntax Guidelines require that the option be a separate argument from its option-argument and that option-arguments not be optional, but there are some exceptions in POSIX.1-2024 to provide for continued operation of historical applications

Thus, it would be reasonable, both from reading the UG and from command line application standards, to assume that whitespace can serve as a delimiter, and not introducing that whitespace between arguments can lead to unexpected behaviour. In this instance, the unexpected behaviour is not something that causes catastrophic failure of the application or corruption or loss of user data, and thus we believe that it is out of scope

Duplicate status (if any):

Duplicate of #3104