产品

分享19种“垃圾代码”,请不要犯此错误!

时间:2024-06-21

“编写好代码”;是对机器学习研究人员和开发人员的最佳补充。

第一个级别意味着您的模型非常好,具有您自己的理解和更正;第二级意味着代码结构,命名规则和编写逻辑都非常出色。

我们曾经将编写代码与编写文章进行了比较:不仅需要有一个主题,告诉其他人代码做什么,而且同时应该在提炼和易读性之间进行权衡。

代码太精致了,总体逻辑很难遵循,代码太易读了,整体显得肿。

简洁和易读之间需要权衡取舍。

第一种方法可以基于列表理解获得更简洁的代码,但是第二种方法更易于阅读。

对于好的代码,我们可以肯定地说一堆规则,例如使用一致的格式和缩进,使用清晰的变量名和方法名,在必要时提供文档和注释,不过度简化代码等等。

但是您对什么是不好的代码有更清楚的了解吗? 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突然失败并且找不到所需的文件或功能,该怎么办。

因此,将代码写入主函数中,而无需维护其他函数导入或代码文件,则此方法是最稳定的。

单个文件一万行代码就可以了,其中一个