-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handling special bearing format + lower/upper casing + tests on invalid input #7513
base: master
Are you sure you want to change the base?
Conversation
inString = inString.substring(0, inString.length - DirectionLabel.West.length); | ||
matchedSuffix = DirectionLabel.West; | ||
} | ||
|
||
// check if the remaining string is a special direction | ||
if (inString.trim() === "") { | ||
const prefix = matchedPrefix?.toLowerCase() || ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seeing how matchedPrefix/matchedSuffix will always come from an enum returning upper case characters, why not avoid having to convert to lowercase here, and change the keys of specialDirections to be all uppercase instead?
if (matchedPrefix === null || matchedSuffix === null) { | ||
return { ok: false, error: ParseError.BearingPrefixOrSuffixMissing }; | ||
} | ||
|
||
const parsedResult = this.parseAndProcessTokens(inString, spec.format, spec.unitConversions); | ||
if(this.isParseError(parsedResult) || !parsedResult.ok) { | ||
if(this.isParseError(parsedResult)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe also remove the RHS of the ||
at the start of parseAzimuthFormat()
as well, to be consistent
#7489
In addition addressing casing and special strings, I added tests for out-of-bound numbers/possible invalid inputs.
Couple observations:
these work as treating the missing sections as 00
4, allows numbers bigger than 90 to occur (tests added in this pr)
The parseAndProcessTokens implementation is relatively loose, which seems acceptable to me. Let me know if any behavior is unexpected.