6 ms·

Long regexes are the root of all evil

crispyambulance 5y ago
Long regex's are not the root of all evil but they're certainly a tendril of bad-practice. I would say that the OP's usage, a home-made concoction to find all opening tags in an xhtml doc, crosses the line into bad practice. Get a room and use a parser, people!
- goto11 5y ago
  So if using regular expressions is "bad practice", how should one write the tokenizer or lexer stage of a parser?
  - crispyambulance 5y ago
    Who said regular expressions are bad practice? Regexes are great but they can get abused easily. Looking more carefully at the SO question, I am inclined to ask "why?" at least a couple of times because I suspect the answer to the deeper problem the SO OP needs to solve can be worked out with a DOM parser. If not, then definitely a SAX parser could solve that specific problem and it would be more robust than handcrafting a fussy regex.
    - goto11 5y ago
      As far as I can tell, a SAX parser does not expose the distinction between an opening tag and a self-closing tag. The tag `<foo />` would just emit a startElement event followed by an endElement, exactly the same as `<foo></foo>`. Which means it can't solve the specific problem the OP describes.
      - crispyambulance 5y ago
        I would rather use a robust battle-tested parser and handle that edge case separately than to create regex for all of xhtml, copied off an opinionated blog, as a "hail-mary".
        goto11 5y ago
        But the question is specifically about that edge case! So how to handle it, if the "robust battle-tested parser" is of no help?
goto11 5y ago
If the task at hand is something which can be solved with a regex, then any other solution (e.g manual string scanning) would be far more complex.
- AzzieElbab 5y ago
  I am guilty of this type of thinking as well. I saw the errors of my ways when I had to fix someone’s else regular expressions
  - goto11 5y ago
    So what do you use instead of regular expressions for such tasks?
    - hansvm 5y ago
      IMO the biggest problem with regexes as seen in the wild is a lack of composability. If you need some kind of pattern like "[setA][setA+setB]{0,n}" then you'll copy-paste the definition of setA in both places. If you need to re-use that entire regex you'll copy-paste it again and construct a monstrous string with a really well-defined structure that isn't even slightly apparent without a reverse engineering session. Up to a point you can solve that by just giving names to relevant sub-expressions, using a regex builder, etc, but in my experience if I'm going to write even a moderately complicated regex I'll probably be better served with something like parsec (a python implementation here [0]) in whichever language I'm currently using. That isn't to say that regexes don't have their place -- anything quick and dirty, situations where you need to handle unsanitized input (mind you, the builtin regex engine is probably vulnerable to exponential runtime attacks) and don't want to execute a turing-complete language, etc.... I just think it has bad ergonomics for any parser you might use more than once, and I haven't yet regretted using parsec in situations where a complex regex would have sufficed. [0] https://pythonhosted.org/parsec/ https://pythonhosted.org/parsec/
      - User23 5y ago
        Perl is great for this. It’s been a long time since I’ve written any, but with the right flags and use of qr// you can write extremely readable perlre.
jrockway 5y ago
Regexes are computer programs just like any other computer program. A long program, terse syntax, embedding one programming language in another programming language, etc. are risk factors for unmaintainable code, but are manageable in the same way that you manage the risk inherent in other complex computer programs. I did always like elisp's "rx"[1] library for removing some of the terseness. Not enough to ever use it, of course, but it's an interesting idea. [1] https://www.emacswiki.org/emacs/rx https://www.emacswiki.org/emacs/rx

Long regex's are not the root of all evil but they're certainly a tendril of bad-practice. I would say that the OP's usage, a home-made concoction to find all opening tags in an xhtml doc, crosses the line into bad practice. Get a room and use a parser, people!

goto11 5y ago
So if using regular expressions is "bad practice", how should one write the tokenizer or lexer stage of a parser?
- crispyambulance 5y ago
  Who said regular expressions are bad practice? Regexes are great but they can get abused easily. Looking more carefully at the SO question, I am inclined to ask "why?" at least a couple of times because I suspect the answer to the deeper problem the SO OP needs to solve can be worked out with a DOM parser. If not, then definitely a SAX parser could solve that specific problem and it would be more robust than handcrafting a fussy regex.
  - goto11 5y ago
    As far as I can tell, a SAX parser does not expose the distinction between an opening tag and a self-closing tag. The tag `<foo />` would just emit a startElement event followed by an endElement, exactly the same as `<foo></foo>`. Which means it can't solve the specific problem the OP describes.
    - crispyambulance 5y ago
      I would rather use a robust battle-tested parser and handle that edge case separately than to create regex for all of xhtml, copied off an opinionated blog, as a "hail-mary".
      - goto11 5y ago
        But the question is specifically about that edge case! So how to handle it, if the "robust battle-tested parser" is of no help?

goto11 5y ago

If the task at hand is something which can be solved with a regex, then any other solution (e.g manual string scanning) would be far more complex.

AzzieElbab 5y ago
I am guilty of this type of thinking as well. I saw the errors of my ways when I had to fix someone’s else regular expressions
- goto11 5y ago
  So what do you use instead of regular expressions for such tasks?
  - hansvm 5y ago
    IMO the biggest problem with regexes as seen in the wild is a lack of composability. If you need some kind of pattern like "[setA][setA+setB]{0,n}" then you'll copy-paste the definition of setA in both places. If you need to re-use that entire regex you'll copy-paste it again and construct a monstrous string with a really well-defined structure that isn't even slightly apparent without a reverse engineering session. Up to a point you can solve that by just giving names to relevant sub-expressions, using a regex builder, etc, but in my experience if I'm going to write even a moderately complicated regex I'll probably be better served with something like parsec (a python implementation here [0]) in whichever language I'm currently using. That isn't to say that regexes don't have their place -- anything quick and dirty, situations where you need to handle unsanitized input (mind you, the builtin regex engine is probably vulnerable to exponential runtime attacks) and don't want to execute a turing-complete language, etc.... I just think it has bad ergonomics for any parser you might use more than once, and I haven't yet regretted using parsec in situations where a complex regex would have sufficed. [0] https://pythonhosted.org/parsec/ https://pythonhosted.org/parsec/
    - User23 5y ago
      Perl is great for this. It’s been a long time since I’ve written any, but with the right flags and use of qr// you can write extremely readable perlre.

jrockway 5y ago

Regexes are computer programs just like any other computer program. A long program, terse syntax, embedding one programming language in another programming language, etc. are risk factors for unmaintainable code, but are manageable in the same way that you manage the risk inherent in other complex computer programs. I did always like elisp's "rx"[1] library for removing some of the terseness. Not enough to ever use it, of course, but it's an interesting idea. [1] https://www.emacswiki.org/emacs/rx https://www.emacswiki.org/emacs/rx