个人if else代码纯净无暇，一个字也不能简化

机器之心报道，参与：刘晓坤、王淑婷、李泽南。

「我曾接手过一个代码，里面是几十个 if else 模块……」对于程序员们来讲，遇到这样的事情应该是苦不堪言的——不少人认为这种写法很是难看、分支众多、容易出 bug。最近，网友们在容器管理平台 Kubernetes 的 GitHub 上发现了这样一段代码，其中的 1700 行 if else 语句却让人叹为观止。

为了防止「头铁」群众真的去重构它，在这段代码的开头，有这样一段注释：

不要尝试简化此代码。

请看着它起飞。

这个控制器是故意以很是详细的方式编写的。你会注意到：

1. 每一个『if』语句都有一个匹配的『else』（除了客户端 API 调用的简单错误检查）

2. 在这里咱们要明确地解释一下

咱们把这种代码叫作『航天飞机风格』。航天飞机风格是为了确保每一个分支和条件都获得考虑——就像在 NASA 编写航天飞机的航天器应用程序代码同样。

最初，这个控制器的工做被分红了三个控制器来作。该控制器是为简化 PV 子系统付出巨大努力的结果。在这种努力中，很明显咱们须要确保在代码中处理和计算每一个条件，即便它致使了无操做代码分支。

所以，控制器代码可能看起来过于冗长，有太多注释和「分叉」。可是，这里记录了大量的业务知识和内容，以确保将来的维护者可以正确地推理绑定行为的复杂性。所以，对此文件的更改应保持航天飞机风格。

该文件的 GitHub 地址：github.com/kubernetes/…

1700 行的 if 嵌套语句。

做为流行的开源系统，Kubernetes 常被用于自动容器化应用程序的部署和管理。其开发者称，Kubernetes 拥有 15 年承担 Google 生产工做负载的经验。对于人工智能领域的开发者来讲，Kubernetes 能够帮助咱们部署深度学习模型（参见：如何使用 Kubernetes 轻松部署深度学习模型）。

航天飞机的风格

据说它是美国航天局 NASA 的代码风格？在 Hackernews 上，众多网友们在通读全文代码后给出了一致好评。

@Klathmon 表示：

我爱死这个了！这简直就是软件开发里的「爵士乐」。它打破了全部的固有「规则」，但目的明确，比按照「规则」来的结果要好得多。

乍一看，你会以为这个文件太大了，里面充斥着许多分支和嵌套 if 语句，还有不少「无心义的注释」，仅描述周围一行或几行代码是作什么的。注释里还有不少 logic，与实际代码相比，这些 logic 很快就会过期或者出错。

但同时，这样作使得维护和管理代码变得简单多了，由于你不用把 logic 拆分红几十甚至上百个文件。它包含了大量对这个文件须要进行的固有复杂工做，而它的注释作得又好又多，作任何改变均可以轻易让注释一块儿更新。

@munchbunny 说：

不能更赞成了。我平常要处理的代码不是这个级别，但也有低级别的特色，一样也比典型的后端代码更接近 metal，被许多的前端和后端代码调用。若是有「甚至更后端代码」的东西，这就是个不错的例子。若是你忽略了一个细微的差异，一群愤怒的开发人员会在部署代码时冲到你办公桌前，而若是你没有快速修复它，就会出现一群愤怒的顾客。

对于任务关键型代码内部循环中的代码来讲，主要的时间成本并非写代码或者理解代码，而是根据所服务场景的细微差异进行优化，检查更改代码带来的直接影响，而后检查更改的二阶和三阶影响。

当你的代码很是细化，以致于你作的每一个改变都有三阶影响时，带有精心注释的代码会更容易维护。由于假如你拼凑了十个不一样的文件，须要花费精力弄清正确的路径，就更有可能忽略其中的细微差异。

关于注释

不少网友对于带大量注释的代码表示颇有用、不反感，而且那些不带注释的代码会带来很大的麻烦。

@EB66 说：

我彻底赞成。对于那些不可避免很复杂的代码，我也喜欢这种风格。

我很是喜欢简洁且语句/命名是表达性的代码，但有时候注释是必要的，以便清楚地阐明逻辑或使用案例。表达性代码能直接传达的含义有限。精心设计的注释能够大大地减小其余开发人员在不熟悉的代码基础上所耗费的时间。

关键是要更新注释。没有比不许确的注释更恶心的事了。检查代码时必定要检查修改过的代码行的注释。

@ascar 说：

解释使用案例或目的的过期注释仍是比没有注释强。它能给你提供背景信息，好比代码的演变及其目的。

只读注释可能比读没有注释的代码更糟糕，因此一些开发人员反感过期的注释，所以就有了通常化（过于简略）的注释。

注释是关于代码的附加信息，没有事实来源，因此，要同时阅读代码和注释。

@nickharr 说：

我有 25 年以上用多种语言编写、查看、注释和检查代码的经验，因此我会说这的确是一个好东西——无论编程的「风格」（或者广义上来讲的语言）如何。

好的代码注释能够对生产力产生巨大的影响——不管是对我的、团队仍是企业来讲都是如此。它有助于存储知识（当前和以前的团队/我的之间容易丢失的信息）。

我我的花了太多时间对那些没有注释的代码进行逆向工程。有时候，经验丰富的程序员或开发人员会走捷径：压缩程序和函数，这些程序和函数是基于他们明确了解的语言和/或领域，但没有对它们进行注解……

在基本层面上，注释应该告知、教育、概述和帮助他人理解咱们写代码时创造的有时很复杂的路径和函数。

有些人认为好的代码不须要注释，某种程度上这是对的，但这一点并不适用于每一个代码库。有些代码很复杂、笨拙，就像意大利面，有时甚至难以理解。

我一直努力教经验较少的开发人员以带点幽默（可能的话）的方式做出高效的好注释——让咱们可以快速理解代码，欣赏前人所作的努力，并笑对复杂的挑战。

我我的并不真正关心代码和注释的比率。有时，代码注释可能比代码自己更有价值。而有时，它们只是帮助你完成工做；只要快速、高效、没毛病，就是不错的代码。

文件大小

@Klathmon 说：

我从事前端网页应用开发，其中最复杂的问题在于如何实现代码库的快速迭代，大部分状况下都不是实际的业务问题。但尽管「deep functionality and small interfaces」听起来很不错，大多数状况下，导出的仅有少许函数的大型文件是不容易维护的。将全部代码放到同一个文件中，须要你在作出任何修改以前确保透彻地理解它们。

@taneq 说：

他们是有目的地这样作的，为了确保开发人员在修改以前能理解整个文件，由于其功能很是关键，很容易被混淆。此外，将一个逻辑严密的文件分割成小型文件（而不是改写成更小的逻辑模块）只会致使没必要要的文件管理问题。

新手的膜拜

@jml7c5 说：

做为一个初学程序员，我很是震惊这居然不是编程的标准惯例。通常的源文件应该提供语境、主题背景、解释概念的参考资料/博客/书籍指南、关于代码如何匹配程序总体的信息，以及（最重要的）文件中体现的思考过程（即为何选择这种作法而不是其它，面临的挑战，权衡等等）。

我仍是想不通，每一位程序员都须要从零开始学习使用一个代码库。除非肯花费数小时来作测试，想改善一个 non-trivial 的程序是不可能的。致开源开发者：若是你想要让人们对项目作出贡献，这些类型的注释是很基本的，更不要说它们能帮助节省很是多的时间。

@qlk1123 说：

「做为一个初学程序员，我很是震惊这居然不是编程的标准惯例。」我赞成这一点，若是这能成为社区标准，固然会有不少人受益。可是，你不认为一个好的社区文化可让人们为此保持良好的习惯吗？

个人平常工做是 Linux 内核开发人员。我发现源代码仅仅是「What」部分，注释中应该声明「How/Why」部分。而且若是这些还不能使我搞明白源代码，我会直接电邮做者问更深层次的「Why」部分。大多数状况下信息都是足够的。

模仿需谨慎

Kubernetes 以外，最近另外一个由于代码而被热议的程序可能就是在 Steam 上火起来的独立国产游戏《太吾绘卷》了。据好奇的程序员介绍，其早期版本中内含数千个 if 语句。因为游戏主创是中文系出身，随后又投身建筑行业，半路出家写游戏代码——最后竟然玩起来没有什么大问题，代码的「糟糕」样式成为了一个梗，为游戏的流行起到了助推做用。

这些著名的案例虽然能够运行，但没有强大的逻辑（运气）是玩不转的。科班出身的程序员们通常就不要模仿了。

参考内容： news.ycombinator.com/item?id=187…