4 ms·

Hmm. Well. I understand where you are coming from, but I don't think it is that 100% that simple. Sometimes a project is 99.99% regex free, but a regex does the

Hmm. Well. I understand where you are coming from, but I don't think it is that 100% that simple. Sometimes a project is 99.99% regex free, but a regex does the exact right thing. For example, say you're working on a project where homomorphic confusion between characters would be a security concern so the charset is restricted but in certain contexts, say, Japanese is expected. A simple: japanese = '([\p{Hiragana}\p{Katakana}]+)' Is all you really need. Concat it with the rest of the strings for the regex and everyone can understand it.

marcosdumay 8y ago
This is one complex regex for you to get the context (it doesn't work anymore, as email validation changed since then): http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html Adding that kind of thing to a project requires a calm cost-benefit analysis and very likely can not be done without the input of everybody working on the project.
- mrfredward 8y ago
  Imagine you need to check if an email address meets RFC822. You can: a) read the 47 page standard and implement every single requirement, one if statement at a time, and end up writing 10s of thousands of lines of code that are nearly unverifiable. b) copy that one regex from the standard, put it in a nice function with a comment on where to find the standard, and move on with your life. Option b will not only save you a week, but also make it much less likely that you screwed up.
  - marcosdumay 8y ago
    What are you building? Almost every time you don't have to do a, you also do not need full email validation. Besides, the regex is wrong, like I said on my comment, so now what do you do? But that's a diversion. You can import a library that will do the same just as well as you can import that regex. Both will have comparable levels of gains and problems, but of very different nature.
    - evilDagmar 8y ago
      Of the two, the regexp from the spec should be preferable, because it is exactly what is in the spec. Some other library would be a once-removed version of it and could actually bring flaws of its own.
  - horsawlarway 8y ago
    Actually, both A and B are incorrect choices. Option A is a complete waste of time. Option B uses a regex that is no longer standards compliant and will tell users that their entirely valid email address is invalid (this is usually a no-no...). You're skipping entirely over option C: c) Send the user an email asking them to validate their email. You'll notice option C is actually the preferred method of almost every company that needs your email to be valid. Option C also does not use a regex at all.
- 3pt14159 8y ago
  Yeah, I agree with you regarding email validators. My overarching point was that I don't think it is an all-or-nothing decision to include regexes. I shy away from them for most projects, but sometimes they're necessary.

marcosdumay 8y ago

This is one complex regex for you to get the context (it doesn't work anymore, as email validation changed since then): http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html Adding that kind of thing to a project requires a calm cost-benefit analysis and very likely can not be done without the input of everybody working on the project.

mrfredward 8y ago
Imagine you need to check if an email address meets RFC822. You can: a) read the 47 page standard and implement every single requirement, one if statement at a time, and end up writing 10s of thousands of lines of code that are nearly unverifiable. b) copy that one regex from the standard, put it in a nice function with a comment on where to find the standard, and move on with your life. Option b will not only save you a week, but also make it much less likely that you screwed up.
- marcosdumay 8y ago
  What are you building? Almost every time you don't have to do a, you also do not need full email validation. Besides, the regex is wrong, like I said on my comment, so now what do you do? But that's a diversion. You can import a library that will do the same just as well as you can import that regex. Both will have comparable levels of gains and problems, but of very different nature.
  - evilDagmar 8y ago
    Of the two, the regexp from the spec should be preferable, because it is exactly what is in the spec. Some other library would be a once-removed version of it and could actually bring flaws of its own.
- horsawlarway 8y ago
  Actually, both A and B are incorrect choices. Option A is a complete waste of time. Option B uses a regex that is no longer standards compliant and will tell users that their entirely valid email address is invalid (this is usually a no-no...). You're skipping entirely over option C: c) Send the user an email asking them to validate their email. You'll notice option C is actually the preferred method of almost every company that needs your email to be valid. Option C also does not use a regex at all.
3pt14159 8y ago
Yeah, I agree with you regarding email validators. My overarching point was that I don't think it is an all-or-nothing decision to include regexes. I shy away from them for most projects, but sometimes they're necessary.