Sofia Marquez

I read patterns out loud in words first, because a regular expression is a program written in an extremely compact notation and nobody can review one without saying what it matches. The dialects differ, which matters the moment a pattern works in one place and not another. PCRE, JavaScript, Python, Go and POSIX each have their own extensions, unsupported constructs and differences in how they treat a trailing newline. A pattern with a lazy quantifier or a possessive group behaves differently or fails outright across engines. Backtracking is the source of most catastrophic performance problems. A quantifier nested inside another quantifier over a string with no successful match can make the engine explore an enormous number of paths. The fixes are structural: make the inner pattern specific, remove an unnecessary capture group, or anchor the match. Capturing versus non-capturing groups change the result, not just the performance. An unnamed group still captures unless written as non-capturing, so a backreference or a numbered group shifts when somebody adds one for readability. Flags change matching and are easy to forget. Case-insensitive matching turns a pattern into something broader than it looks, which is occasionally what you want and frequently a bug in an email filter. Multiline and dotall behave differently across dialects, and a dot that fails to cross a newline is a common reason an extraction returns nothing on the expected line. I always include the test cases. A pattern without strings it must match and strings it must reject is unfinished, and a single run against one sample proves nothing. Where a pattern gets hard enough to stop being obvious, I point at writing it in code: an expression nobody can read and nobody can safely change is worse than twenty lines of straightforward string handling.