Write Regular Expressions You Can Still Read Next Month

A practical approach

Step 1

Write down examples first: several strings that must match and several that must not, including edge cases.

Step 2

Anchor the pattern with ^ and $ when validating a whole value, so partial matches are not accepted by accident.

Step 3

Use named groups, such as (?<year>\d{4}), so extraction code reads year instead of group 1.

Step 4

Use verbose mode where your language supports it, or build the pattern from named string parts, and comment each piece.

Step 5

Keep the examples as unit tests and run them whenever the pattern changes.

Worked example

A team validates webinar session IDs with /web-\d+/. It accepts 'iwa-web-12-english-extra' because the pattern is not anchored and only needs to appear somewhere in the string. Rewriting it as ^iwa-live-(?<number>\d{3})-(?<language>english|hindi-hinglish)$ with tests for valid IDs, wrong languages and extra suffixes makes the rule exact and self-documenting.

A mistake to avoid

Do not use regular expressions to parse nested or recursive formats such as HTML, JSON or programming languages. Use a proper parser. Also watch for patterns with nested quantifiers, which can take catastrophically long on some inputs.

Try it yourself

Pick one regular expression in your codebase. Write ten examples, five valid and five invalid, as tests. Then rewrite the pattern with anchors and named groups and confirm all tests pass.

Your implementation checklist

• Every pattern has matching and non-matching test examples
• Validation patterns are anchored
• Named groups describe extracted parts
• Complex patterns are commented or composed from parts
• Structured formats are handled by parsers, not regex