Invalid naming for input not handled

[nus-pe-bot]

No error is made to handle invalid symbols that should not exist or start with in a name

---

_{[original: nus-cs2113-AY2425S1/pe-interim#359] [original labels: severity.Medium type.FunctionalityBug]}

[NCF3535]

Team's Response

Thank you for the bug report. We appreciate your effort in identifying this behaviour. After careful consideration, we have decided not to restrict names containing symbols, as they are commonly used in real-world scenarios. For example:

• Dr. John A. Doe (e.g., using . in titles or initials)
• Thiru S/O Shanmugan (e.g., using / to denote relationships)
• Tan Je-Deon (e.g names with -)

Additionally, feedback from nurses who have tested this app indicated that they use symbols at the front of names to aid in easier searches, and they liked the fact that we did not reject them. This is despite the fact that there is already a tag feature. For example:

• %John
• @Alice

Allowing symbols provides flexibility and aligns with diverse naming conventions, while also accommodating practical use cases identified by real-world users.

Rationale for Reclassification: We believe the severity of this issue should be reclassified from Medium to Low for the following reasons:

1. No Functional Impact: The user can continue using the program without any hindrance or adverse effects.
2. Legitimate Use Cases: Names with symbols are valid inputs in real-world contexts, and disallowing them might exclude legitimate use cases. For example:
   • . is often used in titles, abbreviations, or initials (e.g., Dr. or Prof. or Mr.).
   • / reflects cultural or personal naming conventions (e.g., S/O for "Son of").
   • Symbols like % and @ may be used intentionally by users for sorting or categorisation.
3. Intentional Flexibility: The current implementation is designed to accommodate diverse user needs, ensuring inclusivity while supporting innovative uses of symbols.

Future Considerations: To improve usability, we could consider implementing a warning for uncommon or potentially invalid symbols (e.g., %, !, >), while still allowing legitimate use cases. However, this is out of scope for this version of the program and could be explored as an enhancement in future updates. In fact, it could also lead to more unnecessary complexity and more bugs.

Thank you again for your report and thoughtful suggestions. Your feedback highlights areas for potential improvement, however we would like to ensure the application remains inclusive and flexible for real-world use.

Duplicate status (if any):

--