“编写良好的代码”是对机器学习研究人员和开发人员更好的赞美。第一层意思是你的模型很好，有自己的理解和修正；第二层是代码结构、命名规则、编写逻辑都非常优秀。我们曾经把写代码比作写文章：你不仅需要有一个主题来告诉别人这段代码做了什么，还需要在精炼性和可读性之间做出权衡。如果代码太精炼，整体逻辑就很难理解，如果代码太容易阅读，整体就会显得臃肿。在简洁性和可读性之间需要权衡。第一种方法可以基于列表推导得到更精简的代码，但第二种方法可读性更高。说到什么是好的代码，我们绝对可以说出一堆规则，比如使用一致的格式和缩进，使用清晰的变量和方法名称，必要时提供文档和注释，不要过度精简代码等等。但是你对什么是坏代码有更清晰的认识吗？GitHub上有一个新项目描述了“最佳垃圾代码”的十九个关键原则。从变量命名到注释编写。这些准则将指导您编写最聪明的错误代码。为了与原GitHub项目保持风格一致，下面不做任何转换。读者可以从相反的角度理解所有的观点，从而完美避免写出垃圾代码。项目地址：https://github.com/trekhleb/state-of-the-art-shitcode当然，以下十九条垃圾代码编写指南并不详尽。如果读者发现一些难以忍受的不良代码习惯，请您可以留言发表您的看法。第一条规则：打字越少越好如果我们打字少，那么我们就有更多的时间去思考代码逻辑和其他问题。如下图，“Good”表示符合规则的例子，Bad表示不符合规则的例子。第二条：变量/函数混合命名方式我们需要混合命名方式和变量，以体现命名的多样性。第三条：反正不写注释，代码都能看懂，为什么要写注释？或者，反正没人看我的代码，我为什么要写注释？第4条：用你的母语写评论如果你违反了第3条的规定，那么至少要用你的母语或其他语言写评论。如果英语是您的母语，那么您也违反了这条规则。既然绝大多数编程语言都是英文的，为什么不评论其他语言呢？第五条：尽可能混合使用不同的格式同样，为了代码的多样性，我们需要尽可能混合使用不同的格式，比如单引号或者双引号。如果它们具有相同的语义，则它们应该混合。第六条：代码尽量写成一行。如果一系列的参数和方法一起实现，那么代码也应该一起写。第七条：发现错误时保持沉默当你发现一些错误时，其他人不需要知道，所以不需要打印日志或Traceback。第八条：全局变量的广泛使用全局变量的使用是“全球化”不可或缺的一部分。第9项：构建备份变量为了以防万一，我们需要创建一些备份变量并在需要时调用它们。第十条：谨慎使用Type。一般不要指定变量类型，也不要经常做类型检查。没有类型是最好的类型。第十一条：准备“PlanB”你需要准备一些无法访问的代码，作为你的“PlanB”。规则12：嵌套三角法如果代码有一些嵌套结构，或者空行缩进结构，三角法则最美。Item13:Mixedindentation我们需要避免使用缩进，因为缩进会使复杂的代码在编辑器中占用更多的空间。如果必须使用缩进，则使用混合缩进策略。当然，这种策略在Python中是行不通的，Python依赖于缩进来确定代码结构。第14条：不要锁定依赖项每次安装新库时，更新现有的依赖项。为什么要维护以前的版本，我们需要时刻保持最新的第三方代码库。第15条：长函数优于短函数。不要把程序的整体逻辑分成一些代码块。如果IDE突然出现故障，找不到需要的文件或函数怎么办？因此，将代码写在一个主函数中，不再维护额外的函数导入或代码文件是最稳定的方法。单个文件10000行代码没问题，单个函数1000行代码也没有问题。第16条：代码不需要做特定的测试这些测试通常是重复的、无意义的工作。第十七条：尽量避免重复代码按照自己的想法写代码，尤其是在小团队中，毕竟这是“自由”的原则。第十八条：新建项目不需要项目前期的README文件，我们可以暂时保持这个状态。第十九条：节省不必要的代码在编写代码的过程中，往往会产生大量的测试代码。这些代码也是很重要的信息，不能删除，最多只能注释掉。
