“编写好代码”；是对机器学习研究人员和开发人员的最佳补充。
第一个级别意味着您的模型非常好，具有您自己的理解和更正；第二级意味着代码结构，命名规则和编写逻辑都非常出色。
我们曾经将编写代码与编写文章进行了比较：不仅需要有一个主题，告诉其他人代码做什么，而且同时应该在提炼和易读性之间进行权衡。
代码太精致了，总体逻辑很难遵循，代码太易读了，整体显得肿。
简洁和易读之间需要权衡取舍。
第一种方法可以基于列表理解获得更简洁的代码，但是第二种方法更易于阅读。
对于好的代码，我们可以肯定地说一堆规则，例如使用一致的格式和缩进，使用清晰的变量名和方法名，在必要时提供文档和注释，不过度简化代码等等。
但是您对什么是不好的代码有更清楚的了解吗？ GitHub上有一个项目，描述了“最佳垃圾代码”的十九个关键原则。
从变量命名到评论撰写。
这些准则将指导您编写最引人注目的不良代码。
为了保持与原始GitHub项目一致的样式，下面不执行任何转换。
读者可以从相反的角度理解所有观点，从而可以完全避免编写垃圾代码。
项目地址：https://github.com/trekhleb/state-of-the-art-shitcode当然，以下十九个垃圾代码编写准则并不详尽。
如果读者发现有一些难以忍受的不良代码习惯，您也可以在后台留言以表达您的意见。
第一个：打字次数越少越好。
如果我们键入的东西更少，那么我们就有更多的时间来思考代码逻辑和其他问题。
如下所示，“好”是指代表遵循规则的示例，而不良代表不遵循规则的示例。
第2条：变量/函数混合命名样式。
我们需要混合使用命名方法和变量，以反映命名的多样性。
第3条：请勿发表评论。
您仍然可以理解代码。
为什么需要写评论？换句话说，既然没有人在看我的代码，为什么还要写注释呢？第4条：用您的母语写笔记。
如果您违反了第三条规则，请至少以您的母语或其他语言书写笔记。
如果您的母语是英语，则您违反了此规则。
由于大多数编程语言都是英语，为什么不用其他语言发表评论呢？第5条：尽可能混合使用不同的格式。
同样，对于代码多样性，我们需要尽可能地混合使用不同格式，例如单引号或双引号。
如果它们具有相同的语义，则应将它们混合使用。
第6条：将代码尽可能地写成一行。
如果将一系列参数和方法一起实现，则代码也应一起编写。
第7条：发现错误时请保持沉默。
当您发现某些错误时，其他人则不需要了解它，因此您无需打印日志或回溯。
第8条：全局变量的广泛使用全局变量的使用是面对“全球化”的必不可少的部分。
第9条：构造替代变量为了以防万一，我们需要创建一些替代变量，并在需要时调用它们。
第10条：应谨慎使用类型。
通常，请勿指定变量类型或频繁执行类型检查。
没有类型是最好的类型。
第11条：准备“计划B”，您需要准备一些无法访问的代码，可用作您的“计划B”。
第12条：嵌套三角规则如果代码具有某种嵌套结构或缩进空行的结构，则三角规则最为美观。
第13条：混合缩进我们需要避免缩进，因为缩进会使复杂的代码在编辑器中占用更多空间。
如果必须使用缩进，请使用混合缩进策略。
当然，这种策略在Python中不起作用，因为它依靠缩进来确定代码结构。
第14条：每次要安装新库时都不要锁定依赖关系，请更新现有的依赖关系。
为什么要维护以前的版本？我们需要始终保持最新的第三方代码库。
第十五条：长功能胜于短功能。
不要将程序的整体逻辑分成一些代码块。
如果IDE突然失败并且找不到所需的文件或功能，该怎么办。
因此，将代码写入主函数中，而无需维护其他函数导入或代码文件，则此方法是最稳定的。
单个文件一万行代码就可以了，其中一个
