Kode Vicious 对阵 Mothra！

在本月的专栏中，Kode Vicious 探讨了从滥用 goto 语句到语言势利眼等各种问题。正如他们所说，这都是日常工作。如果他不是如此强烈反对，我们会让他穿上紧身衣和斗篷，胸前印上大大的 “KV”，然后派他去对抗 Mothra，在那里他会亲自确保你们所有的编码对抗都得到解决。另一方面，如果他坚持使用他的电子邮件帐户，对所有相关人员来说可能更安全，顺便说一句，他的电子邮件地址是 [email protected]。

尊敬的 KV，

我的同事在代码中不断做一些非常糟糕的事情，例如编写带有 goto 语句的宏的 C++ 代码，这些 goto 语句会跳出宏，并在较低级别的函数中使用 assert 作为错误处理机制。我一直在试图阻止他们这样做，但我得到的标准回复是：“是的，这不好看，但它有效。” 我怎样才能让他们开始问：“有没有更好的方法来做这件事？” 他们听取了我的论点，但似乎并不信服。在某些情况下，他们甚至坚持认为他们遵循的是良好实践。

求助

尊敬的求助，

你在信中最可怕的事情是使用 goto 跳出宏。我什至不确定你的同事是如何使用 goto 的，因为这对我来说听起来完全是怪异的。宏应该是在构建时由编译器扩展的本地代码片段，并且它们的副作用应该是本地的。自从 goto 首次出现以来，关于 goto 的使用已经有很多文章，所以我不会再重复这些内容。我也不是一个完全反对 goto 的法西斯主义者：我见过并使用过有效地使用 goto 的代码。在 C 语言中使用 goto 和标签来执行错误清理在许多地方是一种由来已久的传统，并且可以干净地使用。其他用途非常可疑，我希望你的同事用写得好的文档（例如论文或标准）来证明它们的合理性。仅仅说“这是一种好的做法”并不能使它成为好的做法。当他们使用这种古老的绝地思维技巧时，你需要准备好揭穿他们的虚张声势：“这不是你在寻找的代码。”

我认识的大多数程序员最令人喜爱但也令人恼火的特点之一是他们压倒一切的自信感。我的祖母过去常说：“固执的人是愚蠢的人”，我已经开始相信她的话。你面临的问题不仅是技术性的，也是社会性的。在这些情况下，我最常问自己的问题是：“我可以在哪里藏尸，什么时候离开小镇最合适？” 不，等等，不是那个。

说服别人他们错了而你是对的非常困难，而且并不总是那么有趣，除非你为杂志撰写有关它的文章。我建议你保持耐心，这对我来说没问题，因为我不必听从自己的建议。

其他建议是提出问题而不是给出答案。诸如“你是白痴吗？”之类的问题，虽然对灵魂有好处，但对工作环境不利。我的意思是问某人：“你如何调试这样的代码？” 或“我对那种设计模式非常感兴趣；你在哪里学到的？” 如果你能进入他们的思想，即使那可能是一个狭窄的挤压，那么你将更能够改变他们。

尊敬的 KV，

我有一个简单的问题要问你：正确处理 close() 系统调用返回错误的方法是什么？

只是想知道

尊敬的 JW，

我猜你的问题指的是我在 2004-2005 年 12 月/1 月刊的 Queue 中收到的来自 Pointless Returns 的信，我在信中赞扬了检查所有返回码的优点。虽然你可能认为关闭文件描述符时没有什么需要检查的，但这并非事实。在我工作的大多数操作系统上，每个进程的文件描述符都是有限的，我怀疑你使用的操作系统也是如此。将此资源正确返回给操作系统与释放已分配的内存同样重要。

查看我在 Mac OS 10.3（我用来编写这些小文章的操作系统）上的 close() 系统调用，我看到了它可以告诉你的两个可能的错误。第一个是你尝试关闭的文件描述符实际上并未处于活动状态。嗯，这当然是需要注意的事情。这意味着你的程序在某个地方搞砸了，这应该由应用程序记录下来，或者可能导致应用程序以错误退出。

第二个可能的错误是 close 调用被中断，因此没有成功。在长时间运行的程序中，由于 close 未能完成其工作而导致的文件描述符丢失将导致程序在未来的某个时候崩溃，并且以一种难以诊断的方式崩溃。可能需要几天时间才能耗尽文件描述符，并且如果不检查每个使用 close 的地方的返回码，你将永远不知道原因。

所以，我坚持我对 Pointless Returns 的建议。检查任何提供返回码的函数或系统调用的返回码非常重要。

尊敬的 KV，

当我阅读你的专栏时，你给我的感觉就像那些只用 C 或许是 C++ 编程（你会拼错这个词）的人。我们中的许多人使用其他语言编程，例如 PHP、Python 和 Perl。写一些关于这些语言的文章怎么样——也许是写一些在你大多数读者出生后才编写和设计的语言？

在我工作的地方，我们提供大量的 Web 服务，因此我们大量使用 PHP，只有少量的 C 和 C++ 用于执行计算密集型任务，或者必须更接近操作系统的任务。对于我们这些使用其他语言编程的人，你有什么建议吗？

21 世纪程序员

尊敬的 21，

我要让你知道，我出生在 C 语言之后，但只是稍晚一点。我毫不怀疑 Queue 的许多读者都精通其他语言——也许，虽然我一想到就感到不寒而栗，那是 Basic——但我只能写人们询问的内容。曾经有使用 C 或 C++ 以外语言的程序员来信，例如 Linguistically Lost，他在 2004 年 11 月刊中给我写信。如果你提出了一个具体的问题，这会使我的工作更容易，但显然那不是你的目标。至于我的拼写错误，请与我的编辑联系，但我建议你先上几节自卫课。

我读过很多 PHP 代码，以及 Python、Perl、C、C++、TCL、Fortran、Lisp、Cobol 等等。基本事实是，区分好代码和坏代码与语言本身几乎无关。正如 Donn Seeley 最近在 Queue 中指出的那样，你应该学习“如何在任何语言中都不写 Fortran”（2004-2005 年 12 月/1 月刊）。

好的代码使用一种语言中的主导隐喻，使其易于其他人理解。我在这里提到的所有语言都有注释，但许多人要么忽略这些注释，要么完全误用它们。自 1980 年代以来，编写可理解的变量和函数名称已成为可能，但人们仍然继续使用单个字母，认为那些在他们之后查看代码的人会知道它们的含义。

在 PHP 中，你可以这样写
function getn($data)

以及像这样简单地写
// 此函数在 name_field 中接受字符串作为输入
// 名称必须是以字母开头的字符串
// 字符，即 A..Z 或 a..z，并且长度不得超过 32 个字符
// 字符长度。只有第一个字符必须是
// 字母，所有后续字符可以是
// 字母或数字，即 0..9

function get_name($name_field)

尽管如此，人们仍然继续编写第一个版本。所以，我不在乎你和你的年轻朋友有多么现代——你必须应用编写易于理解的代码的基本知识，以便其他可怜的程序员第一次阅读它时就能理解。一旦你完成了这些，请就 PHP 提出一些具体问题，这些问题将阐明其时尚、现代的感觉，然后我们就可以谈谈了。

KODE VICIOUS，凡人称之为 George V. Neville-Neil，以编写网络和操作系统代码为乐和营利。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探勘、操作系统和重写你的烂代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，自 1990 年以来一直以旧金山为家。

最初发表于 Queue 第 3 卷，第 4 期—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，加密哈希存在许多标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍认为，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来提供关于该主题的新见解，以研究生产力方面的差异。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，在这个世界中，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在追求快速前进的过程中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略针对它面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，后来普及，是这些成熟的解决方案之一。