峰间的云
图片信息：Pexels 上的 cottonbro 拍摄的照片
今天朋友们讨论到一个正则问题，是需要校验六位数字密码，要求不能六位都是相同的数字（111111、222222等是不允许的），也不能【全】都是连续的数字（123456是不允许的，但是128345是允许的）。
然后有个朋友搜到了网上找到的一个正则表达式：
/^(?:(\d)(?!((?<=9)8|(?<=8)7|(?<=7)6
|(?<=6)5|(?<=5)4|(?<=4)3|(?<=3)2|(?<=2)1
|(?<=1)0){5})(?!\1{5})(?!((?<=0)1
|(?<=1)2|(?<=2)3|(?<=3)4|(?<=4)5
|(?<=5)6|(?<=6)7|(?<=7)8|(?<=8)9){5})){6}$/
（上面这段代码为了方便阅读也做了换行处理，实际是一行代码）
这个正则属于太长不看系列，我并没有测试网友写的对不对。这种正则对项目是破坏性的，因为可读性非常差，你让后面的同事怎么维护相关代码？写注释？项目忙或者团队开发者意识/情绪欠佳的情况下，谁能保证当后面需求迭代相关校验规则被修改后，备注一定会被同时更新？如果没更新，类似的备注可能反而埋下了隐患，后续重构者觉得这段正则可读性差可能直接按照备注的说法改成迭代前的校验逻辑了。
最好的代码可读性，是代码自身的可读性，而不会注释的可读性。注释只能起辅助——除了那种确实代码没法做到有较好可读性的情况。
那这题怎么处理呢？直接JS写判断逻辑是不错的选项，或者直接正则暴力枚举，像下面这样：
/^((?!012345|123456|234567|345678|456789 |987654|876543|765432|654321|543210|000000 |111111|222222|333333|444444|555555 |666666|777777|888888|999999).)*$/
（上面这段代码为了方便阅读也做了换行处理，实际是一行代码）
意不意外？有时候枚举值少的时候，最好的方法就是暴力枚举。生活里也是这样，很多时候我们觉得会有捷径，花了很多时间去找捷径，结果反而没有直接去做来得干脆利索。
