21CTO导读：林纳斯再次对内核小组写的代码发出斥责，他称一些人在写垃圾代码。

最近，Git 和 Linux 的创建者林纳斯·托瓦茲 (Linus Torvalds) 就Meta 工程师最近发布的 PR ，发出了严厉斥责。

邮件列表内容如下：

图片来源：

https://lore.kernel.org/lkml/CAHk-=wjLCqUUWd8DzG+xsOn-yVL0Q=O35U9D6j6=2DUWX52ghQ@mail.gmail.com/

以下，是翻译过来的中文。

不行。这是个垃圾，而且提交得太晚了。我要求尽早提交拉取请求是因为我正在出差。如果你不能遵守这条规则，至少也要把拉取请求做得好一点。

这样会增加各种垃圾，这些垃圾并不是 RISC-V 指定的通用头文件。

我说的是真的“垃圾”。这些东西谁也不应该发给我，更别提在合并窗口后期。

就像这个疯狂而毫无意义的 make_u32_from_two_u16()“helper”。

这玩意儿让世界变得更加糟糕了。它就是一堆没用的垃圾，让任何用户都无法理解，比不用那个愚蠢的“helper”还要糟糕。

如果你把代码写成“(a << 16) + b”，你会知道它做了什么，以及哪个是高位字。也许你需要添加强制类型转换，以确保“b”的高位不会影响最终结果。所以，虽然结果可能不太美观，但也不会出错，不会难以理解。

相反，如果你写 make_u32_from_two_u16(a,b)，你根本不知道它的词序是什么。换句话说，你这样只能把事情弄得更糟，而且你把那个“辅助函数”添加到了一个通用的非 RISC-V 文件里，而人们使用它后来让其他代码也变得更加糟糕。

所以这样绝对不可行。这类事情需要改正。它不会出现在通用头文件中，而且绝对不会在合并窗口后期发生。

（尽管这个拉取请求发送得很晚，但我还是同意了）

我认为这是一个“每件事都写两遍”或“是的，请重复一遍”的好例子，正如我之前写过的。

林纳斯之前写的文章链接地址（作者按）：

https://read.engineerscodex.com/p/4-software-design-principles-i-learned

现在我们有了更好的编码代理，我认为这里的 PRY 原则实际上比以前更重要。

林纳斯在这里提出的主要观点是，好的代码会进行优化，可以减少认知负荷。

减少微上下文切换

如今，程序代码拥有多个阅读者：计算机、大语言模型（LLM）和软件工程师。

人类和大语言模型每次在“上下文窗口”中能够存储的上下文数量是有限的。要理解一个新的文件或函数，需要进行轻微的上下文切换，并且需要额外的脑力（和标记）来吸收这些新信息。

现在，LLM 必须理解一个新文件、一个新路径和一个新增的函数。因此，一个始终不使用任何辅助函数的函数，比一个拥有 5 个辅助函数的函数所需的上下文和脑力更少。

神经科学表明，切换任务会产生我们可测量的大脑能量消耗。跨文件切换是一种微上下文切换。

辅助/抽象越多，“切换成本”就会越大。

人类的工作记忆容量有限的。假如人脑一次只能存储 4-7 个“块（block）”。每个抽象或辅助函数都会占用一个块槽。每个抽象都会消耗更多令牌（Toke）。层数过多会导致认知超负荷。使用过多令牌则会增加出错的几率。

相关网址（作者按）：https://github.com/zakirullin/cognitive-load

这意味着，有时，重复实际上是在减少认知负荷，因为“块”是自包含的。

当然，有时候抽象组件和函数也是合理的。例如，如果你想在整个代码库中强制执行某种行为，那么辅助函数可能是一个不错的选择。

另一方面，对于简单的操作，代码被重复使用，是完全没问题的。仔细想想，你真的需要那个辅助文件或抽象类吗？

事实上，它使代码更清晰、更易理解，最重要的是，更容易迭代。使用 Claude Code 或 Codex 指向一个文件并让它进行修改要容易得多，而不需要通过深度搜索 3-4 个不同的文件，才能完全理解“父”文件的上下文。

在性能工程中，“引用局部性”（保持数据/代码紧密相连）对于提高效率至关重要。

PRY 就像是一种认知引用局部性。

最后提一个同样重要的事，过早优化的成本从未如此之高，尤其是在现代 IDE 和 LLM 的时代，代码重构成本比以往任何时候都要低。

代码重复的成本已经下降，并且未来还将继续下降。

善良不要付出代价

Linus 在提出观点时有一点需要注意：语气和粗鲁无礼。当然，每个人的工作方式都不一样，但友善一点总是好的 :)。

粗鲁与无礼会让提交代码成为一种风险。没有人愿意为了写代码而冒着被公开斥责的风险，就像上面提到的那样。

在这一点上，Abhinav提出了一些建议，我认为他说得挺好：

林纳斯提出的观点是正确的，但他的风格却并非如此。这将为年轻一代树立一个错误的榜样，让他们也变得像这类情况一样，具有破坏性。你可以对代码提出批评，但不要使用侮辱性的言辞。

我已经看到过足够多的引用，指出这并非基于事实。由于风格问题我不会合并他们的代码，那么他如果我告诉我的同事，们将会学习并修正它，而我不必将其贬低为垃圾来造成人们的心理创伤。

优化沟通，以减少认知负荷。

作者：洛逸