如何使用编程规则和指南

根据 Arne Mertz 的说法，使用编程规则和指南有助于开发人员协同工作，因为它们可以产生更一致、更好的代码。然而，如果使用不当，则会产生相反的结果——代码难以阅读，或者以次优甚至错误的方式解决问题。

Arne Mertz 在 NDC Tech Town 发表了关于编程规则和指南的演讲。

Mertz 解释了规则和指南之间的区别：

规则或多或少是绝对的。无论规则应用在哪里，都必须遵守，违反规则通常是不可接受的。

指南是一种最佳实践或合理的默认做法——我们可能有产生分歧的理由，但这没关系。

了解这种差异是很重要的，因为将指南解释或陈述为规则会导致开发人员破坏代码，而不是破坏指南本身，Mertz 认为：

指南的本质是，在某些情况下，它们并不适用，并且在这种情况下，试图坚持应用它们往往会导致代码变繁琐、可读性变差，甚至导致完全的错误。

Mertz 说，对于开发人员来说，严格的规则似乎更方便。编译器对其接受的内容非常严格。我们有太多复杂的问题需要解决，盲目遵循一套规则会让我们负担过重。

在他的演讲中，Mertz 探讨了一些规则和指南。他解释了“不要使用异常”（“don’t use exceptions”）规则的由来：

近二十年来，我看到“不要使用异常”规则（或指南）在各种情况下出现。当你追溯它的起源时，你会发现它是来自谷歌风格指南，其中说到“我们不使用异常”。

Mertz 表示，这种微小的差异非常重要，因为它表明谷歌不使用异常。该风格指南阐述了原因；这并不是因为异常被认为是不好的，而是因为在谷歌，有很多代码在编写时并没有考虑异常。对这样的代码库引入异常会带来引入未定义行为的风险，并且需要重新编写其现有代码库的大部分内容，正如 Mertz 所解释的那样：

Mertz 说道：“谷歌是出于必要才采用了这一指南的，而且，据我从在谷歌工作过的人那里了解到的情况看，并不是所有地方都遵循了这一指南。”。

Mertz 表示，在项目中应用这一指南时，指出它的起源以及它是针对旧的大型项目这一事实可能会导致该指南被弃用；当然，除非到那时，这个有问题的项目也已经发展了多年，并且没有考虑异常，而引入异常到这些项目中会导致与谷歌采用该指南同样的问题，他补充道。

Mertz 探索的另一条规则是“每个函数都应有一个返回（return）语句”。该规则是几组指南和规则的一部分，例如 MISRA C 和 MISRA C++ 规则。正如 Mertz 所解释的那样，制定这一规则的原因各不相同：

一些人认为长函数的可读性更高，但反驳的观点是首先应该缩短函数。在像 C 这样的语言中，过早返回可能会意外忽略资源清理，这样是很糟糕的。

Mertz 提到，当你将 C++ 与 RAII 类一起使用，该论点并不适用，因为编译器能通过析构函数来保障资源的清理。

InfoQ 就遵循编程规则和指南可能产生的影响采访了 Arne Mertz。

InfoQ：你对“不要使用异常”的指南有什么看法？

Arne Mertz：异常是 C++ 语言报告错误的核心特性。不经常使用异常会导致过多地使用错误返回码和输出参数，从而使代码变得更难阅读和推理。像 std::expected 这样的现代库解决方案可以在一定程度上缓解这些问题，但我从未见过它们被用于因谷歌指南而避免异常的项目中。

我推测，尤其是在 21 世纪初，谷歌作为一家软件公司是一个时髦的榜样，所以人们都想要效仿他们。他们在完全不同的代码库中采用了这一指南，而没有质疑它的必要性。

InfoQ：遵循“每个函数都应该有一个返回语句”的规则会有什么影响？

Mertz：遵循该规则通常会导致“retVal”变量的某些变体，这些变体通常会被初始化为一个无意义的值，希望稍后能被赋值为实际的返回值。此外，我们经常看到用一个变量来跟踪我们是否在一条正确的道路上，或者跟踪一个深度嵌套的控制流。所有这些模式都会使代码变得更加复杂，并降低可读性。

作者介绍

Ben Linders 是一位来自荷兰的敏捷、精益、质量和持续改进方面的独立顾问。他著有《从敏捷回顾中获得价值（Getting Value out of Agile Retrospectives）》、《Waardevolle 敏捷回顾（Waardevolle Agile Retrospectives）》、《是什么推动了质量（What Drives Quality）》、《敏捷自我评估游戏（The Agile Self-assessment Game）》、《问题？什么问题？（Problem? What Problem?）》以及《持续改进（Continuous Improvement）》。并且是许多敏捷辅导工具的创建者，例如敏捷自我评估游戏。作为一名顾问、教练和培训师，他通过部署有效的软件开发和管理实践来帮助组织。他专注于持续改进、协作和沟通以及专业发展，为客户提供商业价值。Ben 是敏捷、精益和质量网络的活跃成员，也是一位经常演讲和写作的人。他在一个双语博客（荷兰语和英语） 中分享自己的经验，并在 InfoQ 担任敏捷方面的编辑。可以通过 @BenLinders 在推特上关注他。

查看原文链接：

https://www.infoq.com/news/2024/11/programming-rules-guidelines/