903
what debugging regex feels like
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Feb 2025
903 points (98.4% liked)
Programmer Humor
25448 readers
1160 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
I found your email address:
HOWD YOU GET MY PASSWORD?!?
Appropriate username.
I was about to ruin your day by finding a valid email address that would be rejected by your regex, but it doesn't even parse correctly on regex101.com
The only valid regex for email is
.+@.+btwIt's the RFC standard regex for email, so it's definitely valid, btw. My copy/paste just seems to add a bunch of backslashes for some reason
The argument here is that checking complex validation is a fool's errand. Yes, you can write a fully validating regex for RFC email. In fact, it should be possible to write a regex shorter than the one that gets passed around since the 90s, because regular expression engines support recursive patterns now. (Part of the reason that old regex is so complicated is because email allows nested comments (which is insane (how insane? (Lisp levels insane)))).
However, it doesn't get you much of anywhere. What you really want to know is if it's a valid email or not, and the only way to do that is to send an email to that address with a confirmation. The only point of the regex is to throw away obviously bad addresses. For that, checking that there's an @ symbol and something for the user and domain portions is sufficient. I'd add needing a dot in the domain portion, but it's not that important.
Classically, it was argued that emails don't even need a domain portion when things are done for internal systems, or that internal domains don't need a tld. In my personal experience, this is rarely done anymore and can be safely ignored. Maybe some very, very old legacy systems, and if you're working on one of those, then sure. For everyone else, don't worry about it. You're probably working on publicly accessible systems, and even if you're not, most users are going to prefer using their fully spec'd out email address, anyway.
Cool story bro, go argue with the IETF
Why? Do you think nested comments are a good idea?
Deleted by user.
Where did you get that "RFC standard" regex? It doesn't allow domain names with one component RFC5321
Neither does it allow spaces in quoted string, as per RFC5322
This, ๐@โ๏ธ.gg, is already a working email address in most clients and if RFC6532 ever gets accepted, it would be officially recognized as such.
My point isn't to make your regex bad, just that it doesn't validate or invalidate an email properly. Nothing stops me from giving you and invalid but syntactically correct email after all.
You have to send an email anyways to verify, so the most you can check is the presence of one @ symbol.
What about
"user@not_domain"? It validates but isn't valid - there's no domain part, the@is quotedThat's not something you can determine using a regex.
"user@com" for example could be a perfectly working email.
The right way is to send a verification email in every case.
Does this regex include
"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.comYes
https://regex101.com/r/h5XOd0/1
That
\\.part doesn't look right, but what do I know. Apparently control codes are valid elsewhere, so a literal backslash followed by any character, even a space or a newline, might actually be valid there."Yeah, my e-mail address is abc, carriage return, three backspaces and a terminal bell at example dot com. ... What do you mean your mail program doesn't support it?"