Open nus-se-script opened 1 week ago
Thanks for pointing it out but this is intentional. Our choice is based on this section of the textbook:
Overzealous input validation: ... In general, it is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software. Allowing such flexibility can in turn allow the software to be used in ways you didn't even anticipate while overzealous rejection of inputs can annoy the user. Example 1: While your software allows only one phone number in input values, a user might want to input 1234 5678 (HP) 1111-3333 (Office) -- blocking that input might not add any value but allowing it does.
To allow more flexible user input, our app does not check the validity of every single input (separated by spaces), as mentioned in the UG. We believe allowing at least one valid input is a reasonable design choice, i.e. fixing it is less important than the work done in the current version of the product.
Also, the reason we chose 2 to be the threshold is because in some countries like France, phone numbers are grouped into 2 digits, i.e. in the format of xx xx xx xx xx.
--
It is unreasonable to have at least 1 token which is a valid phone number after separating by space. If I key in
1 2 3 4 5 6 7 8
which is not allowed,12 3 4 5 6 7 8
should not be allowed either because it does not make sense to allow one but disallow the other.Suggestion: ignore all white spaces and check whether the resultant string is a valid phone number, after extracting out the format (the country code and the 24 hours)
[original: nus-cs2103-AY2425S1/pe-interim#3088] [original labels: type.FeatureFlaw severity.Low]