点击上方“程序猿技术大咖”，关注并选择“设为星标”

回复“加群”获取入群讨论资格！

作者丨Marcin Gajda 译者丨马可薇

策划 | 万佳  来源｜ InfoQ

本文将向你展示五种糟糕的代码实践，它们足以让所有程序员深恶痛绝。

1将变量命名变成解谜游戏

图译：parseDBMXML 代指什么：A、解析 DBM XML 。B、解析 DB MXML。C、解析 DB Mx 标记语言。D、解析 DB Mx 机器学习。

首先，从最简单的开始，在函数命名或变量命名时画蛇添足，使用不必要的缩写字母。好的代码实践会建议人们在命名时尽量清晰表达其用途，比如handleFormSubmit、getUserConfiguration，或者是parseCustomerInformation。

而糟糕的代码实践是在命名中尽可能地使用缩写和简写，这样接手你代码的下一位开发者得靠猜测才能搞明白你想做什么。

像handleBtnClick、getConfig，或是parseInfo这样的命名就挺随意。从这些名字里不太看得出函数的用处，但别人做代码审查的时候还是可以接受它们的。不必要的缩写更能让别人困惑，btn、func、config，或者 cb，个个都太难懂了。

变量命名能动的手脚就更多了！有一个未确认用户的列表？别写unconfirmedUsers，直接用users，这样接手的开发者得通读你全部代码才能搞清楚这个变量指的是什么。对付这位可怜的开发者也别用 discountedProducts，直接用 product 这个名字足矣。

想要再添把火？可以，大小写就是你的下一个玩具，我向你保证，接手你代码的同事绝对会恨死你。别用优秀代码例子中的readXmlDocument这种命名了（缩写的大小写应与其他单词大小写形式相同），readXMLDocument 才会让其他的开发者们更仔细地阅读你的代码，更认真地读你的变量名才能想明白你要表达什么。

当然，这些迷惑手法都会死在代码审核阶段，但你可不会就此躺平不是？或许是因为懒癌发作不想改，或许是因为你的叛逆个性作祟，但不管怎么说，你永远可以夸下海口，在下一次的 PR 中做出修正，并双手合十祈祷你的同事会原谅你的罪孽（指不定他们就原谅你了）。

2复杂化代码

图译：我：试图在一个调用中写完整个功能

不知道你是否有过证明自己是软件开发界的 Rick Sanchez（瑞克和莫蒂中的一个奇怪且酗酒的疯狂科学家）的机会。

你要做的仅仅是对你的代码进行些不必要的复杂工序。

比如通过一般化的手法，在两个地方重复利用三行代码？你要做的也就是写个接受五个变量的小函数而已。再精明一点，你还可以把这三行代码缩写到一个精密的三层嵌套三元操作里！想象力无极限，我的朋友！

当然，这些会让应用 更难读懂也更难维护，但这些负担大概只会落到你同事的肩膀上，对吧？那可真是太棒了！

那么快来试试，用代码来证明你才是真正的黑客。我会建议你试试链式函数、嵌套条件语句、过度膨胀的设计模式，以及利用编程语言中不为人知的小技巧编写的精妙的单行代码。如果我们可以用更加神秘的+new Date()，那么为什么还要用老套的Date.now()呢？我相信你同项目的同事在研究你代码到底在搞什么的时候，一定会深深地感谢你的！

请记住，越是过于精巧以及过早优化的代码，你同事经手它们时的境遇就会更糟糕。为你所使用的每一个 reduce 函数加十分尊敬分，为每一个递归调用加一百分。在项目的最后，你一定会成为一名真正的编程高手，加油！

3混乱的 import

图译：我：试图解释项目的依赖阶层

之前我们提到这些绝招很可能在代码审查阶段就不幸落命，但如果你是使用 JS 或 PSP 的 web 开发者，那么在你所有的文件开头大概率都会有一连串的 import 或 use 语句。开发者们在做审查时基本不会管这些东西，他们只关心那些更有料的部分。

这也就是为什么依赖是个乱搞代码的好地方。

试着想象一下，你在 React 中有个叫UserSubscriptions的 view，然后再创建个叫calculateTimeToSubscriptionEnd的 helper 函数。那么，现在问题来了，你要把这个 helper 函数放在哪？在存放所有和订阅或付费相关的域逻辑的单独文件里？多没意思。不如直接放在你刚新建的 view 旁边！

再提前规划下最后创建管理面板以及这个例子里的Subscription view 的情况，你大可直接从 user 的 view 里 import 你想要的 helper 函数，毕竟没人会在乎区区 import 列表。两个毫不相关的模块搅在一起，别人再想修改或重构你的代码就得费好大的功夫。相信我，开发者们最最憎恶的莫过于是结构稀烂的项目。

你说什么？“这还不够混乱”？小菜鸟程序员们很可能在短时间内都不会动你的代码，他们会在你创造的一团乱麻中苦苦挣扎，想着保险起见还是保持原样最好。而每当有新开发者尝试理解你的项目结构，都会带来新一轮的折磨，当开发中更新或者删除了什么你在 import 中提到的东西，也会让这份折磨加倍返还。对所有人都有百害而无一益的混乱局面，只有勇士才能拯救的局面，或许你可以尝试成为这名勇士？

4运行方式不同的同一函数

图译：男：在管理界面我加了个新的用户相关节点，会返回新的数据那种

女：是会像其他那些用户相关节点一样，接收用户 ID 的对吧？

男：（你说呢）

女：……是会像其他那些用户相关节点一样，接收用户 ID 的，对吧？

或许你会认为自己是有创造力的，并且很有艺术感的人。请容我向你介绍，这一全新的折磨方式。

世界是瞬息万变的，没人说过所有东西都必须一成不变。也没人说过一致性和可预测性是优秀开发经验和成功项目的关键。也许真的有人说过，但我们也不一定要听他们的不是？

我们的任务是通过让代码库中的一个函数拥有一点点的可变性，来毁掉别人的美好一天。

举例来说，一个验证函数，数据验证通过会返回 True，验证失败则会返回一条失败信息。那么，如果这个函数会在数据正确的情况下返回 False 或未定义，你的同事大概就要再多写几个情况来处理你的返回了，这岂不美哉。

当然，你也可以在所有函数中都接受不同形状的参数。拿上面这张梗图为例，让一些函数接受用户 ID，另一些则在完全可以只用用户 ID 的情况下接受整个用户对象。或许你还可以找到些接受用户电邮地址的方法？接手你代码的家伙要面临的可就是地狱啊。

你甚至还可以再添加一点惊喜的元素，让一切都变得不可预测起来。管他的一致性，随机性万岁！当然，别再惦记着整个代码库了，一个文件一个文件地改过去多好。工程师有什么意思，不如做个艺术家快活自在！我相信你的开发者同僚们一定会打心底地恨着你。但这又有什么用呢，你已早早领先了。

5把代码复制黏贴得到处都是

图译：我的代码库：把其他文件里的同一段代码复制黏贴到不同文件里

等你这么做了之后，我相信没人会想再和你共事了。

别把相同逻辑分散到不同的函数、类、组件里去。只复制黏贴你需要的那几行代码就够了。

毕竟，你的代码是完美且意义非凡的，所有人都要在项目中的不同部分重复看到很多遍才够。让你的代码发光发热吧！

但你也知道，这并不是你疯狂复制代码的原因。在一些更新中，系统会要求开发者们同时更改大量文件内容。如果测试范围不够，某些人可能会忘记删掉一两次的重复逻辑，并不得不开始第二次甚至是第三次的更新。还有什么是比在成千上百的文件中搜索重复代码更有趣的事呢？你的同事们一定会乐在其中的。

记得我说过好的缩写很难并且非常浪费时间吗？那么我们为什么不直接在需要的地方把代码复制过去呢？不然的话，你大概还要再花时间向别人解释你为啥要不断复制你之前的代码。我相信你，你一定可以做到的！

6总结

很明显，这篇文章就是图一乐。请千万不要尝试我在文中描述的这些操作，这可不是什么可以“赌五毛”的小玩笑。

请一定要在实践中按相反的来：

• 代码中的命名保持清晰明了

• 代码要简单易懂

• 保持整洁的项目结构

• 记得使用常量以及可预测的界面

• 在保持代码清晰的同时分割相同逻辑

以及最重要的一点，善待你的同事们！

在开发社区中流传着这样一个说法，在你编写代码时，永远要像是被连环杀人犯接手你的代码一样。你可不想被一个连环杀人犯盯上，对不对？而我则认为，你更应该在写代码时，想象着如果下一个接手这份代码的人是你自己，你会怎么想。在你编程时，请一定要问问自己，“如果我早就不记得这些程序是干什么的时候，我会乐意看到这些代码吗？”

原文链接：https://tsh.io/blog/bad-coding-practices/

感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！

• 可视化接口管理平台 YApi，让你轻松搞定 API 的管理问题

• 构建基于Spring Cloud向Service Mesh框架迁移的解决方案及思路

• MySQL性能优化(七)：MySQL执行计划，真的很重要，来一起学习吧

• 微服务架构下的核心话题 (三)：微服务架构的技术选型

喜欢就点个"在看"呗，留言、转发朋友圈