Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Regex Isn't Hard (2023)

timkellogg.me

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Regex Isn't Hard (2023)

#101

Post by reverendsteveii »

Supermancho wrote: post #94
reverendsteveii wrote: post #91

Earlier quoted context omitted.

I haven't verified it but quick googling for a regex to validate all legal email addresses pointed me to https://stackoverflow.com/questions/201323/how-can-i-validat... , where one commenter posits that regex to be: (?:(?:\r\n)?[ \t]) (?:(?:(?:[^() @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["() @,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t])) "(?:(?: \r\n)?[ \t]) )(?:\.(?:(?:\r\n)?[ \t]) (?:[^() @,…

> 'What value does this add over just verifying that the input is of the form {something}@{something}.{something}?' Depends if {something} can contain periods for my email. name@antispam.mydomain.com

something is defined as any string of valid characters greater than 0 in length. I'm sure there's some char somewhere that breaks this but in a realistic setting with normal users you won't encounter that edge case and if you do the worst that happens is an email gets returned as non-deliverable

Re: Regex Isn't Hard (2023)

#102

Post by kelafoja »

bazoom42 wrote: post #58
kelafoja wrote: post #30

Earlier quoted context omitted.

My problem is that regexes are write-only, unreadable once written (to me anyway). And sometimes they do more than you intended. You maybe tested on a few inputs and declared it fit for purpose, but there might be more inputs upon which it has unintended effects. I don't mind simple, straight-forward regexes. But when they become more complex, I tend to prefer to write out the procedural code, even if it is (much) lo…

> I tend to prefer to write out the procedural code, even if it is (much) longer in terms of lines. This might work for you, but in general the amount of bugs is proportional to the amount of code. The regex engine is alredy throughly tested by someone else while a custom implementation in procedural code will probably have bugs and be a lot more work to maintain if the pattern changes.

That is quite a generalization. The regex engine is tested, but my specific regular expression isn't. My ability to write correct regular expressions is weak, so there can be many bugs in the one line of regular expession.

Re: Regex Isn't Hard (2023)

#103

Post by kelafoja »

bazoom42 wrote: post #95
rerdavies wrote: post #90

Earlier quoted context omitted.

In general, the correctness of the code is proportional to its readability. I also prefer procedural code instead of regexes.

Surely complexity is a factor? A procedual implementation will necessarily have the same essential complexity as the regex it replaces, but then it will additionally have a bunch of incidental complexity in matching and looping and backtracking. Regexes can certainly be hard to read - the solution is to use formatting and comments to make them easier to understand - not to drown the logic in reams of boilerplate code…

> A procedual implementation will necessarily have the same essential complexity as the regex it replaces

I don't think I fully agree with this, and I don't see a basis for why this should be true. If I have a very specific implementation, it could have very little incidental complexity, it could be fully targeted to the use case. Whereas with regular expressions there is incidental complexity of the regex engine itself by definition.

Re: Regex Isn't Hard (2023)

#104

Post by kelafoja »

fragmede wrote: post #34
kelafoja wrote: post #30

Earlier quoted context omitted.

My problem is that regexes are write-only, unreadable once written (to me anyway). And sometimes they do more than you intended. You maybe tested on a few inputs and declared it fit for purpose, but there might be more inputs upon which it has unintended effects. I don't mind simple, straight-forward regexes. But when they become more complex, I tend to prefer to write out the procedural code, even if it is (much) lo…

You know you can write comments in your code where the regexp is, right?

You know that there are more friendly sounding ways to give this suggestion, right?

Re: Regex Isn't Hard (2023)

#105

Post by krackers »

lairv wrote: post #50

My issue with regexes is that the formal definition of regex I learned at university is clear and simple [0] but then using them in programming languages is always a mess [0] https://en.wikipedia.org/wiki/Regular_expression#Formal_lang...

The issue is the formal definition of regex only deals with whether a string belongs to language recognized by regex or not (boolean accept/non-accept), but regex in practice often talks in terms of "find the substring (if any) that matches". Which then causes issues because a regex is equivalent to an NFA so a given string can be matched in possibly multiple ways, which forces you to bring in the notion of a "greedy" vs "non-greedy" match in order to disambiguate. And then add in top of that the desire to define sub-matches in terms of capturing groups, and it's just a complete mess. And that's not even getting to not-strictly regular PCRE extensions like lookaround, backreferences, etc.

Re: Regex Isn't Hard (2023)

#106

Post by bazoom42 »

kelafoja wrote: post #103
bazoom42 wrote: post #95

Earlier quoted context omitted.

Surely complexity is a factor? A procedual implementation will necessarily have the same essential complexity as the regex it replaces, but then it will additionally have a bunch of incidental complexity in matching and looping and backtracking. Regexes can certainly be hard to read - the solution is to use formatting and comments to make them easier to understand - not to drown the logic in reams of boilerplate code…

> A procedual implementation will necessarily have the same essential complexity as the regex it replaces I don't think I fully agree with this, and I don't see a basis for why this should be true. If I have a very specific implementation, it could have very little incidental complexity, it could be fully targeted to the use case. Whereas with regular expressions there is incidental complexity of the regex engine its…

Complexity in the standard library is not that relevant. If you make your own custom dictionary implementation, you increase complexity of your code base compared to just using the one in the standard library, even if your own implementaion is simpler.

The relevant complexity for using a regex is the complexity of the pattern itself and the complexity of invoking the regex. Any custom procedural solution will be more complex unless it is literally something as simple as checking whether a string contain a given literal string.

Re: Regex Isn't Hard (2023)

#107

Post by rerdavies »

bazoom42 wrote: post #106
kelafoja wrote: post #103

Earlier quoted context omitted.

> A procedual implementation will necessarily have the same essential complexity as the regex it replaces I don't think I fully agree with this, and I don't see a basis for why this should be true. If I have a very specific implementation, it could have very little incidental complexity, it could be fully targeted to the use case. Whereas with regular expressions there is incidental complexity of the regex engine its…

Complexity in the standard library is not that relevant. If you make your own custom dictionary implementation, you increase complexity of your code base compared to just using the one in the standard library, even if your own implementaion is simpler. The relevant complexity for using a regex is the complexity of the pattern itself and the complexity of invoking the regex. Any custom procedural solution will be more…

For some arbitrary definition of complex.

Re: Regex Isn't Hard (2023)

#108

Post by [deleted] »

kelafoja wrote: post #102
bazoom42 wrote: post #58

Earlier quoted context omitted.

> I tend to prefer to write out the procedural code, even if it is (much) longer in terms of lines. This might work for you, but in general the amount of bugs is proportional to the amount of code. The regex engine is alredy throughly tested by someone else while a custom implementation in procedural code will probably have bugs and be a lot more work to maintain if the pattern changes.

That is quite a generalization. The regex engine is tested, but my specific regular expression isn't. My ability to write correct regular expressions is weak, so there can be many bugs in the one line of regular expession.

[deleted]

Re: Regex Isn't Hard (2023)

#109

Post by bazoom42 »

kelafoja wrote: post #102
bazoom42 wrote: post #58

Earlier quoted context omitted.

> I tend to prefer to write out the procedural code, even if it is (much) longer in terms of lines. This might work for you, but in general the amount of bugs is proportional to the amount of code. The regex engine is alredy throughly tested by someone else while a custom implementation in procedural code will probably have bugs and be a lot more work to maintain if the pattern changes.

That is quite a generalization. The regex engine is tested, but my specific regular expression isn't. My ability to write correct regular expressions is weak, so there can be many bugs in the one line of regular expession.

If you have made a bug in the specification of the pattern to match, then you will have the same bug in the hand-rolled implementation of the matching. It will just be more difficult to find the bug since the pattern is not explicitly specified anymore.
Post reply on HN