On 23/08/2017 14:36, Juergen Schoenwaelder wrote:
On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
1) Email address. I understand that the full regex to validate all email
addresses is very complex, but checking that it at least contains an @
symbol still has benefit. It would seem that a short imperfect regex is
better than a complete perfect regex.
What is your definition of 'better'? A stricter pattern catches more
errors. An imperfect pattern is better than none.
My definition of 'better' is:
- is relatively easy for a human to read/review.
- doesn't exclude any valid values.
- doesn't check numerical ranges, only the number of digits.
- is simple enough to trivially work with most normal regex engines.
- otherwise the pattern is as strict as possible given the constraints
above.
2) A list of VLAN ranges, e.g. want to allow strings that look like this:
"1-10,20-400,600,2000-3000", but only with non overlapping values in
ascending order. It is easy to write a regex to check that the structure is
right, but AFAIK it is hard (impossible?) to write a regex that ensures that
the ranges don't overlap and are specified in ascending order.
So what. Does this provide a helpful argument whether patterns should
be strict or imperfect?
My point is only that it is very easy to produce invalid config that
passes whatever regex is used so it is better to produce a simpler and
more human readable regex rather than expand it to perform range
checking of numerical values as well.
So, I propose that we use regexes for checking that the string is
structurally correct, but don't use regexes to perform numerical range
checks of string encoded numbers, since it makes the regexes hard to
read/verify, and doesn't improve the readability of the YANG file either.
So here is the point I think:
It is desirable that regexes are as strict as they can be.
However, if regexes become so complicated that they become a
verification and maintenance problem by themself, then less strict
regexes may be a better choice.
I partly agree, but the line of where I would define a regex as being
too complicated may be different from you ;-).
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
