手牵手教你写垃圾代码，从入门到精通

假如说到什么是好代码，我们一定都能说出一堆规则，例如使用一致的格式和缩进、使用清晰的变量名和方法名、在必要时提供文档与注释、不要过度精简代码等等。

但是对于什么是烂代码，你有比较清晰的认识吗？

在 GitHub 上有一个新项目，它形容了「最佳垃圾代码」的十九条关键原则。从变量命名到注释编写。这些原则将指导你写出最亮眼的烂代码。

为了保持与原 GitHub 项目一致的风格，下文没有进行转换。读者们可以以相反的角度来了解所有观点，这样就能完美避免写出垃圾代码。

repo 地址：
trekhleb/state-of-the-art-shitcode

当然，以下十九条垃圾代码书写原则并没有面面俱到，假如读者们发现有少量难以忍受的烂代码习惯，也可以留言发表你的看法。

第一条：打字越少越好

假如我们键入的东西越少，那么就有越多的时间去思考代码逻辑等问题。如下所示，「Good」表示遵循该规则的示例，Bad 表示没遵循该规则的示例。

image.png
第二条：****变量/函数混合命名风格我们需要混合命名方法与变量，这样才能表现命名的多样性。image

第三条：****不要写注释反正代码都看得懂，为什么要写注释？或者者说，反正没人看我的代码，为什么要写注释？

image

第四条：****使用母语写注释假如你违背了第三条规则，那么至少写注释需要用你的母语或者者其它语言。假如你的母语是英语，那么你也算违背了这条规则。既然编程语言绝大多数都是用英文，那么为什么不用其它语言注释一下？

image

第五条：****尽可能混合不同的格式同样，为了代码的多样性，我们需要尽可能混合不同的格式，例如单引号或者双引号。假如它们的语义相同，那就应该混用。

image

第六条：****尽可能把代码写成一行假如一系列参数与方法都是一起实现的，那么代码也要写在一起。

image

第七条：****发现错误要保持静默当你发现某些错误时，其余人不需要理解它，因而不需要打印出日志或者 Traceback。

image

第八条：****广泛使用全局变量使用全局变量，是面向「全球化」不可或者缺的部分。我是一名前台程序员，最近发现有很多简书的同学在学习前台的时候，感觉学的没有方向，越学越迷茫，这样的情况一般都是学习方法开始就是错误的。没有把前台技术进行专业系统化的学习。从就业和节约时间的角度考虑，假如有谁遇到这方面的问题，可以随时问我，由于我做前台也比较久了，对于这些问题比较理解。或者者加入我创立的学习交流裙，需要资料的可以问我。-282549184 https://www.songma.com/p/95a4f90459af

image

第九条：****构建备用变量以防万一，我们需要创立少量备用变量，在需要时随时调用它们。

image

第十条：****Type 使用需谨慎一般不要指定变量类型或者者经常做类型检查，无类型才是最好的类型。

image

第十一条：****准备「Plan B」你需要准备少量运行不到的代码（unreachable code），它们可以作为你的「Plan B」。

image

第十二条：****嵌套的三角法则假如代码有少量嵌套结构，或者者说缩进空行的结构，三角法则是最漂亮的。

image

第十三条：****混合缩进我们需要避免采用缩进，由于缩进会使复杂代码在编辑器中占用更多的空间。假如肯定要采用缩进，那么就使用混合缩进策略。当然，这种策略在 Python 中是行不通的，由于它靠缩进来确定代码结构。

image

第十四条：****不要锁住依赖项每一次要安装新库时，升级已有的依赖项。为什么要维持之前的版本呢，我们需要时刻保持最新的第三方代码库。

image

第十五条：****长函数比短函数好不要将程序整体逻辑分割为少量代码块，要是 IDE 忽然不行了，它找不到必要的文件或者函数怎样办。因而把代码写在一个主体函数中，并且不再维护额外的函数导入或者代码文件，那么这样的方法是最稳固的。单个文件一万行代码是没问题的，单个函数一千行代码也是没问题的。第十六条：****代码不需要做特定测试这些测试通常是重复且无意义的工作。第十七条：****尽量避免重复代码按你的想法写代码，尤其是在小团队中，毕竟这是「自由」原则。第十八条：****构建新项目不需要 README 文档在项目前期，我们可以暂时保持这种状态。第十九条：****保存不必要的代码在写代码的过程中，经常会产生很多测试代码。这些代码也是非常重要的资料，因而不能删除掉，最多只能注释掉。