Comment by mrkeen a day ago
This stuck out:
email_t theEmail = parseEmail(untrustedInput);
if (theEmail == PARSE_ERROR) {
return error;
}
It's the parse-versus-validate hill in this case.
This pseudocode is "Validate" for at least 3 reasons:
Forgetting to check:
this check is fragile: it’s extremely easy to forget. Because its return value is unused, it can always be omitted, and the code that needs it would still typecheck.
First, it’s just annoying. We already checked that the list is non-empty, why do we have to clutter our code with another redundant check?
Second, it has a potential performance cost. Although the cost of the redundant check is trivial in this particular example, one could imagine a more complex scenario where the redundant checks could add up, such as if they were happening in a tight loop.
Use a data structure that makes illegal states unrepresentable. Model your data using the most precise data structure you reasonably can. If ruling out a particular possibility is too hard using the encoding you are currently using, consider alternate encodings that can express the property you care about more easily. Don’t be afraid to refactor.
It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead. This is validate, not parse.
> It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead. This is validate, not parse.
I feel this kind of fundamentalism is letting the perfect be the enemy of the good.
Every C programmer is already doing it the 'good' way (validation), so this article doesn't really add anything.
The only fundamentalism involved in PdV is: if you have an email, it's actually an email. It's not arbitrary data that may or may not an email.
Maybe you want your emailing methods to accept both emails and not-emails in your code base. Then it's up to each method to validate it before working on it. That is precisely what PdV warns against.
I'm not smart enough to suggest a fix here, I'm just pointing out that this article is not the PdV from the well known article.
But I can spot when code is doing exactly what the cited article says not to do,
This line is the "validate" in the expression "parse, don't validate":
if (theEmail.error != PARSE_OK)
You'd be better off reading the original: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
> and I don't take 'pseudocode' as an excuse
Weird hill to die on, since neither email_t nor PARSE_ERROR were defined in the sample snippets. How do you know PARSE_ERROR is not email_t?