"Clean code that is simply a hoax!"

What code is clean code, how code is not it? - in fact, clean code is a big lie, no one will write clean code.

Author | Chad Befus

Translator | meniscus, Zebian | Guo Rui

Exhibition | CSDN (ID: CSDNnews)

The following is the translation:

I (the code clean way) to "Clean Code" book love and hate.

Over the years, I taught a course in professional software engineers to use this book. I read this book again and again a dozen times, each time a new harvest. That being said, I found the book, half of the content is wrong. I hope that this book covers, other people, my mentor and my own experience learned lessons, but I think from what the code is "clean code" Speaking; more precisely, from what code is not "clean code" Speaking.

What code is not clean?

Determine whether the code neat problem is that this goal is entirely subjective. If you let seven experienced and accomplished software engineer to define clean code, then eventually they will give you the definition of seven very different. "Clean Code" Chapter VII of the book has proved this point.

On the other hand, dirty code is very objective. I can write a piece of code, each seeing engineers agree that this code mess.

This means that from dirty to clean the code has a code range, an end of the objective, the objective than the other end. The following figure illustrates this point briefly.

In the figure above, a group of engineers several code samples were graded. Then, each sample divided by the average order. We use the same degree of a certain level of tolerance. As you can see, with the increase of the average deviation score increases.

If clean code is subjective, then we write code for other more realistic goal? Reduce the mess of code count as a goal?

Defined mess

Before clearly defined messy code, we should first agree on the factors affecting priority codes for practical purposes. I think the following are some of the important aspects, there is no specific order.

Efficient: Using minimal resources (time, memory, etc.) to complete the work.
Robust: even if the input is wrong, it is reasonable to deal with.
Delivery: Delivery time is minimized.
Correct: Upon receiving the good input and returns the correct output.
Scalable: the difficulty of adding new functionality small.
可运行：最小化为代码达到可运行状态付出的工作。
灵活：改变代码工作方式的难度很小。
可靠：我们很自信修改代码不会出错。
可读：将另一位工程师理解代码所需的时间降到最低。

这些都是人们在定义整洁的代码时常常讨论的方面。你可以考虑一下在你心目中这些因素的优先顺序。

虽然我说了这些方面没有特定的优先顺序，但其实则不然，上述顺序与我心目中的优先顺序正好相反。如果代码具备可读性，那么所有工程师都可以理解代码，这意味着他们可以轻松地实现其他方面。实际上，“阅读旧代码所花费的时间比例超过了10:1。每次写新代码的时候，我们都需要阅读旧代码。”如果代码易于理解，则易于测试、修改和运行。因此，也易于扩展、修复、部署和改进。最后，如果交付到实际客户的手中，则可以提高某些地方的健壮性和效率。

因此，我们的优先级可分为四层：

可读。

可靠，灵活，可运行。

可扩展，正确，交付。

健壮，高效。

每一层都服务于下一层的实现。鉴于此，我们可以将脏乱的代码定义为难以阅读的代码。

代码的可读性因人而异，因为每位开发人员的经验水平各不相同，熟悉的软件范式、编程语言、代码库、编译器、操作系统等也不尽相同。而且最重要的是，读代码的人与作者之间从来都没有完全相同的文化和词汇。我们力求做到为大多数人提供最方便阅读的代码。

Suess博士的著作《The Cat in The Hat》（戴帽子的猫）的读者数量超过了James Joyce的著作《Ulysses》（尤利西斯），也是因为这个原因。因为前者的受众范围更广，读起来更简单。当然，我们可以争论哪本杰作更伟大，但是我们不会争论哪本书的阅读难度更高。

我认为，在审阅代码这件事上，傻瓜比天才更出色（这也是为什么我认为我很擅长代码审阅）。当一个傻瓜遇到一段聪明、预料之外、有副作用、不容易懂的代码时，他们会为之苦恼，因此他们会毫不犹豫地指出这些问题。而当一个天才阅读这段代码时，他们的大脑会飞快地运转，并在短时间内消化所有的代码。尽管傻瓜遇到问题时不一定知道该如何修复，但代码审阅过程中，确定问题确实存在才是关键的第一步。

因此，傻瓜和天才都有各自的弊端。幸运的是，无论你认为自己更倾向哪一种，都可以坚持做好一件事情：不断提高自身，以及编写代码的能力。

工匠精神

没人能在学习建筑的第一天就建造出泰姬陵。无论你身处何处，眼前都有一段很长的路需要走下去。严格来讲，每个人距离完美都遥不可及。

作为一名作者，是撰写骗取点击量的文章，还是撰写有意义的文章，二者之间有本质的区别。大千世界里这两种类型的作者都不罕见，可能骗取点击量的文章确实可以获得更多的点击。但是你想成为哪一种呢？

作为一名工匠，你不必担心人们的赞美或衡量最终结果的标准，你应该为自己的全力以赴而感到自豪。此外，你还需要不断提高自己的技术力。

工匠的作品会受到同行业中其他人的称赞，而那些不懂行的人往往会忽视。工匠关心的是作品的质量，对于编写代码来说，就是代码的可读性。你的代码不一定完美，但你应该努力将脏乱度降到最低。除此之外，你应该原谅自己过去的一无所知。最重要的是，你应该向所有人学习，甚至是那些不了解你的才能的傻瓜。

速度很重要

你的产品和项目经理会很关心你的速度。关心质量是你的本职工作。一位出色的经理明白，无论从时间还是金钱上来讲，工程都是编写代码的过程中最昂贵的部分，因此优化这部分资源在金钱的角度来看也很有意义。高质量、可读性强的代码可以最大程度地减少繁琐的代码债务并提高速度。然而，更常见的是幼稚的经理只看重当前冲刺或季度冲刺的收益。

想象一下，你找了一家公司处理税务。公司就像你的经理一样，希望工作人员尽快完成尽可能多的税务评估，以确保他们可以获得最大利润。但是，如果税务专业人员的工作质量不佳，那么就让会让公司面临诉讼、声誉受损和长期失败的风险。保证工作质量，并防止这种风险是税务工作人员的责任。每个职业都是如此。律师与服务的公司，医生与医院，机械师与商店。如果你事先知道某个员工不愿意坚守工作质量，那么你还愿意雇佣他们吗？软件工程师也不例外。

工匠应该在不牺牲工作质量的情况下尽快交付产品，他们对此持有坚定的立场。所以，我们的问题是，如何在编写高质量（具有可读性）的代码和经理能够忍受的交付速度之间取得平衡？对我而言，找到最佳平衡的方法是：首先编写代码来解决和理解问题，再经过可读性的优化后，最后交付代码。通常，我知道我的代码仍有改进的空间，但是就我的技术水平而言，如果这些改进是显而易见的，那么我会在第二次修改代码时改进。而且之后我还会在每次修改代码或添加新功能时，反复改进。

编写脏乱度较低的代码

关于如何编写更好的代码，网上有大量的媒体讨论，例如书籍、博客、视频等等。通常他们都会列举你需要遵守的一系列规则。然而问题在于，这些规则之间往往是相互冲突的。很多人都认为这些规则并没有什么用，或者是可以忽视的观点。的确，在软件开发中，每个规则都可能有例外，但是不能仅仅因为你无法时时刻刻都遵循这些规则，就否定你应该尽可能地遵循它们。

有关这方面的规则有很多，我们应该从哪里开始呢？我的建议如下：

1、有简单的规则，也有复杂的规则。首先学习简单的规则。这些是你的基础，因此请务必正确理解这些简单的规则。

2、每个优先级都有各种规则，你首先应该学习可读性的规则，然而再学习第二优先的规则。

3、有些规则可以频繁使用，而有些规则仅适用于特定情况，请先学习前者。

4、有些规则是错误的。如果它与许多更简单、更重要和更实用的规则相冲突，那么可以暂时忽略。

最后，那些相互冲突的规则又当如何呢？作为技术人员，这个问题无可避免，你应该根据需要解决的问题，选择更优先的规则。