写出别人也能维护的正则表达式

有一类代码，写它的人当时清楚明白，三个月后连自己都看不懂——正则表达式正是其中的典型。一条能跑通的正则，远不等于一条好正则。当它被塞进代码里、没有注释、又长又密时，任何想修改它的人都会如临大敌，生怕一动就出错。写出别人也能维护的正则，靠的不是炫技，而是几条让模式变得可读、可测试、可推理的习惯。

能跑通不等于好

很多正则之所以难维护，是因为作者只追求"让它工作"，却忽略了"让它能被读懂"。一条几十个字符、毫无结构的模式，哪怕功能完全正确，也是一颗定时炸弹：下一个需要改它的人，往往只能推倒重来，因为没人敢在不理解它的情况下修改。

把"可维护"当成正则的一项硬指标，而不是可选项。一条稍微长一点但清晰的模式，远胜过一条精巧却无人能懂的模式。

许多正则引擎支持"宽松模式"，允许在模式里加入空白和注释而不影响匹配。这让你可以把一条长正则拆成多行，每一段旁边写明它的意图。原本一团乱麻的符号，就变成了一份有解释的文档。

哪怕引擎不支持内联注释，也至少应在代码旁边用一段说明，讲清这条正则想匹配什么、为什么这么写。注释的成本极低，回报却很高。

支持命名捕获组的引擎，让你能给捕获的片段起一个有意义的名字，而不是靠数字编号去引用。(?<year>...) 比"第二个括号"清晰得多，读代码的人一眼就知道这段在捕获什么。

同样，把一条复杂正则拆成几个有名字的小片段，再组合起来，也能极大提升可读性。命名是让隐含意图显式化的最廉价手段之一。

面对一个复杂的匹配需求，与其硬塞进一条巨型正则，不如把它拆成几个较小、各司其职的部分，在代码里分步处理或组合。每一小块都容易理解、容易测试，整体逻辑也更清晰。

有时甚至该问一句：这个问题真的需要正则吗？某些任务用普通的字符串处理反而更直白、更好维护。正则是工具，不是必须证明自己的目的。

正则的行为常常出人意料，尤其是在边界情况上。一条没有测试的正则，等于一段没人验证过的逻辑。为它写一组测试用例，既要覆盖应当匹配的输入，也要覆盖应当被拒绝的输入，还要特意包含那些容易出错的边界。

有了测试，你日后修改这条正则时就有了安全网：改完跑一遍，立刻知道有没有破坏原有行为。这对"没人敢碰"的正则尤其重要。

正则很容易诱使人炫技，用各种高级特性把逻辑压缩到极致。但过度聪明的模式往往以可读性为代价。当一条正则需要资深工程师盯着看半天才能理解时，它在团队协作里就是负债。

优先选择直白、易懂的写法，哪怕它略长一些。代码是给人读的，正则也不例外。清晰，永远比精巧更有价值。

还有一条重要的边界：正则不擅长解析嵌套、递归的结构，比如完整的 HTML 或复杂的编程语言。强行用正则去做这类事，往往得到一条脆弱、难懂、还容易出错的怪物模式。

遇到结构化数据，请用专门的解析器。把正则用在它真正擅长的地方——匹配相对简单、规律明确的文本形状。守住这条边界，你的正则才会既好用又好维护。