04 ESLint和Dijkstra-评点茹炳晟文章中的一段话

评点茹炳晟文章中的一段话（01）关于设计模式

02 关于敏捷-评点茹炳晟文章中的一段话

03 重构和Fowler的奇怪-评点茹炳晟文章中的一段话

本文要评点的以下这段话，来自茹炳晟老师的文章《从未实现“工程化”的软件工程（写在《AI 时代人月神话》出版之前）》，https://mp.weixin.qq.com/s/S1a_IH-IfYsoF2cHGFgGqw。

和之前的评点一样，我把茹炳晟老师的这段话标了编号，逐一评点。

原文[04]

你现在愤怒地对着eslint红色波浪线咒骂的那条"函数不能超过50行"。这个可能来自1970年代Dijkstra的思想，经过几代人的提炼，最终变成了一条自动执行的规则。

评点1

“可能来自”的表达不合适

原文描述了程序员提交代码时被代码检查工具挡住而破防的场景，并把该检查工具的某个可配置规则和某位计算机科学家的思想建立因果关系。

论证这样的因果关系不是不可以，但应该认真检索，仔细求证，使用“可能”和“几代人的提炼”来减少求证的工作量，是不合适的。

我之前在这篇文章中批评了“貌似”表述：

评Thoughtworks 首席咨询师林宁的《OOP和DDD其实就是对现实的比喻》（https://mp.weixin.qq.com/s/IRPiaDD-C2ZnolWO0op0jQ）

评点2

“函数不能超过50行”不是“自动执行的规则”。

50只是ESLint中max-lines-per-function规则中max选项的缺省值。这个值可以设置为其他整数。

（https://eslint.org/docs/latest/rules/max-lines-per-function）

另外，max-lines-per-function不是官方推荐配置缺省启用的规则。

（https://github.com/eslint/eslint/blob/main/packages/js/src/configs/eslint-recommended.js）

也就是说，项目使用ESLint官方推荐配置，不会因此启用函数代码行数限制，除非开发者自行配置或使用第三方配置。

更有意思的是，ESLint以前是缺省不启用任何规则的。以下是ESLint 1.0.0的发布页面：

（https://eslint.org/blog/2015/07/eslint-1.0.0-released/）

因此，茹炳晟老师说的“自动执行的规则”是错误的。

当然，也许我说的这一切，茹炳晟老师已经熟知。他只是说：配好了规则当然就会自动执行了！那就当我没说。

评点3

即使抛开ESLint不谈，说“限制函数的代码行数”来自Dijkstra的思想，证据不足。

首先，没有发现ESLint官方把这条规则和Dijkstra联系在一起。

如果抛开ESLint不谈，“限制函数的代码行数”和Dijkstra的思想是否有可以考证的继承关系？

Dijkstra的代表性论文《Go To Statement Considered Harmful》，发表于1968年，文章的主题是讨论不受约束的goto跳转会破坏程序的可理解性，主张使用更有纪律的控制结构。这篇文章并没有涉及限制代码行数。

如果要找证据，翻遍Dijkstra整个学术生涯的著作，大概率能找到和“限制函数的代码行数”关联的文字，毕竟都属于程序设计的问题。

但是，对于熟悉计算机科学历史的人来说，如果要问，看到“限制函数的代码行数”，第一反应想起哪一位计算机科学家？同样获得图灵奖的Niklaus Wirth比Dijkstra更合适。

Wirth的代表性论文，1971年的《Program Development by Stepwise Refinement（通过逐步求精进行程序开发）》，截图如下：

在论文中，Wirth还吐槽了Fortran：

Wirth并不白白吐槽，后来他的Pascal成为计算机科学教育的最主流语言，霸榜时间超过二十年。

以上只是说，如果非得安排一个人，Wirth比Dijkstra更合适，无意论证“限制函数的代码行数”来自Wirth并经过几代人提炼。

===以下是扩展==

为什么我要从Wirth的论文中摘出Fortran这一段来呢？因为茹炳晟老师在这里犯的错误和前面提过的林宁犯的错误又颇为类似——想绑定一个人但绑错了。

林宁的原文写：

面向过程的语言依然还是图灵模型解决问题的思路:有限的有序指令序列。只不过这里的指令从机器语言、汇编代码换成了容易理解的表达式而已

在下面这篇文章中，我评点到此处，说了一句“把图灵和冯·诺依曼搞混了吧？”，就“待续”了。

评Thoughtworks 首席咨询师林宁的《OOP和DDD其实就是对现实的比喻》

在本文中，把这个“待续”续上。

Fortran语言的主要设计者John Backus在他的图灵奖演说论文《Can Programming Be Liberated from the von Neumann Style?（编程能否从冯·诺依曼风格中解放出来？）》中说得很明白：

传统编程语言基本上就是冯·诺依曼计算机的高级、复杂版本。

（Backus并没有袒护Fortran）

林宁的原话搞混了图灵和冯·诺依曼。

从“解决问题的思路”来说，图灵机是状态机的思路，不是线性的指令序列。

（尽量不用“图灵模型”，可以用“图灵机”、“图灵机模型”或“图灵计算模型”，因为另有生物学术语“图灵模型”。）

特别是，林宁说的是“指令序列”，图灵机的“指令序列”（不是指令集合）不一定是有限的。

我们看教材：

状态有穷，符号有穷，那条纸带可以无穷。

以上评点的用语，图灵机是“解决问题的思路”、图灵机的“指令序列”，其实也是不妥的，但为了评点，顺着林宁的话强行这样说。

原文[05]

软件工程的代际传承，是活的知识在活的人群中的流动，不是文件的归档，而是心智的播种。

==待续==