zhlint v0.3.2 发布，一个粗糙的中文 Markdown 文档风格检查器，开发过程的一点感想

然而，事实上搞起来是挺痛苦的。一方面的原因，是 mistune 的解析行为主要由其定义的 regex 决定， regex 读起来相当痛苦，通过一边猜一边用 Debuggex 解析 regex 的方式，用了大概一天才把整个逻辑搞懂；另一个方面的原因是 mistune 在设计的时候并不 care 解析出来的 Markdown Element 的位置信息，为了得到这些信息我必须做一些奇奇怪怪的 Hack ，主要的耗时也在这一步。最终使用继承 mistune 基类的方式自己搞了个 Markdown Parser 出来。

「 Parser 的部分搞定了，之后应该就是一帆风顺了吧，毕竟 Parser 的 Hack 应该是最脏的部分了。」这是我测完 Parser 的想法，现在看来还是太天真了。与检测、修复文档风格的逻辑相比， Parser 的部分「脏的程度」简直不值一提。

为了检测文档风格错误，需要考虑：

由什么风格是需要检测的？
通过什么方式来检测？

第一点还好，我仔细分析了 DaoCloud 的写作规范，提取了十余条可以自动化判断的规则，见支持的检查项目。然而，这些规则还是比较模糊的，当时没有仔细的思考每一条规则的边界条件，导致后续花费了很多时间在修 bug 上面。

对于第二点，我打算用 regex 来搞，每一条规则定义出一些错误的 case ，然后用一组 regex 来命中这些 case 。

"Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." from Jamie Zawinski

不说了，都是泪，各种边界条件搞不清楚，每次遇到新的无法处理的 case 只能手动把这个 case 泛化之后加进规则里，然后祈祷这条规则不会与其他规则冲突。而且 regex 里各种奇奇怪怪的用法也把我虐得半死，什么 non-capturing 、 look-ahead 、 look-behind 、 catastrophic backtracking ，非常可怕！

就拿 E201 ，只有中文或中英文混排中，一律使用中文全角标点这条规则为例。

触发 E201 的、有风格错误的样例有：

有中文, 错误.
中文'测试'
中文"测试"
LaTeX 公式 $$.
LaTeX 公式,$$
LaTeX 公式 \(\).
LaTeX 公式,\(\)

正常的样例有：

有中文，正确。
有中文，正确......
P.S. 这是一行中文。
LaTeX 公式 $$
LaTeX 公式 \(\)
邮箱： [email protected]
有中文， 1.0
有中文， www.google.com
链接地址 http://google.com

要用 regex 来表达出这种差异，还是挺蛋疼的。

万幸的是，这些坑我基本上都解决了。然而，通过这种类似「撞大运编程」搞出来的规则，我自己也不知道前面会有多少的坑，所以我在标题里讲 zhlint 是一个「粗糙的」中文 Markdown 文档风格检查器。反正 dog food 了一段时间之后感觉还是稳定的，已经能满足我自用的需求了，有什么问题以后慢慢再修。

之后就是自动修复的功能了，这个其实还是比较简单的，直接跑一个 LCS 得到原始文本与 parsed 后文本的映射关系，然后把在 parsed 后文本的修改操作映射回原始 Markdown 文本即可。虽然这部分涉及的算法应该是最多的，但并没有花多少时间。

总体的感想：