Regular expressions: matching what you mean

Goal

Write patterns that accept exactly the intended inputs, run in predictable time, and can be read by the next person.

Prerequisites

A precise description of the accepted language: which characters, which lengths, which structure.

Steps

1. Use fullmatch (or ^...$ with the right multiline semantics) for validation; search finds a substring anywhere and accepts far more than intended.
2. Prefer explicit classes ([A-Za-z0-9_-]) to \w and . when Unicode letters or newlines are not wanted; remember that \w matches all Unicode word characters in Python 3.
3. Bound repetition with lengths ({1,64}) instead of unbounded +/* on validation paths.
4. Avoid nested or overlapping quantifiers such as (a+)+ or (\w+\s?)*: on non-matching input they backtrack exponentially (ReDoS), which OWASP documents as a denial-of-service vector.
5. Write longer patterns with re.VERBOSE and comments; compile once at module level.
6. Keep a table of inputs that must match and must not match as unit tests, including empty strings and Unicode.

Expected result

Patterns that fail fast on wrong input, run in linear time on hostile input, and document themselves.

Limits and test basis

Regular expressions cannot validate nested or recursive structures (HTML, JSON); use a parser. Different engines differ in syntax and Unicode handling; test in the engine you deploy. Guidance follows the cited sources.