Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
It appears that most modern languages and tools allow for extended regular expressions, and ERE looks a lot cleaner than BRE with all those backslashes. Are there any major drawbacks in compatibility or maintainability when using ERE instead of BRE?
I don’t think “BRE vs. ERE” is a very useful distinction these days. There are still many tools based on ERE, like awk and gnu grep, as well as the regex support in databases like MySQL and Oracle, but BRE is practically a footnote.
Moreover, the regex flavors built into most modern programming languages go way beyond ERE in terms of features. Even JavaScript, the least powerful of the lot, supports non-capturing groups, reluctant quantifiers, and lookaheads. It would probably be more helpful to classify regex flavors as “ERE vs. ECMA+”, but there’s a lot more to it than that.
If you’re programming in Tcl, you use
\yand\mto match word boundaries; in JavaScript you learn to love[\s\S]because there’s no dot-matches-newlines mode; in Visual Studio you use@and#instead of*?and+?for minimal matching. And, although Java has a thoroughly modern regex flavor, it has no regex literals and no raw/literal/verbatim string notation, so you go blind from looking at all the backslashes anyway.In practice, this isn’t really a choice you have to make anyway. Once you’ve decided which tool to employ, you use whatever regex flavor it demands.
ref: Flavor comparison chart