程序员应规避的 5 种糟糕的代码实践
本文将向你展示五种糟糕的代码实践，它们足以让所有程序员深恶痛绝。
将变量命名变成解谜游戏
图译：我：试图在一个调用中写完整个功能
不知道你是否有过证明自己是软件开发界的 Rick Sanchez（瑞克和莫蒂中的一个奇怪且酗酒的疯狂科学家）的机会。
你要做的仅仅是对你的代码进行些不必要的复杂工序。
比如通过一般化的手法，在两个地方重复利用三行代码？你要做的也就是写个接受五个变量的小函数而已。再精明一点，你还可以把这三行代码缩写到一个精密的三层嵌套三元操作里！想象力无极限，我的朋友！
当然，这些会让应用更难读懂也更难维护，但这些负担大概只会落到你同事的肩膀上，对吧？那可真是太棒了！
那么快来试试，用代码来证明你才是真正的黑客。我会建议你试试链式函数、嵌套条件语句、过度膨胀的设计模式，以及利用编程语言中不为人知的小技巧编写的精妙的单行代码。如果我们可以用更加神秘的+new Date()，那么为什么还要用老套的Date.now()呢？我相信你同项目的同事在研究你代码到底在搞什么的时候，一定会深深地感谢你的！
请记住，越是过于精巧以及过早优化的代码，你同事经手它们时的境遇就会更糟糕。为你所使用的每一个 reduce 函数加十分尊敬分，为每一个递归调用加一百分。在项目的最后，你一定会成为一名真正的编程高手，加油！
混乱的 import
图译：男：在管理界面我加了个新的用户相关节点，会返回新的数据那种
女：是会像其他那些用户相关节点一样，接收用户 ID 的对吧？
男：（你说呢）
女：……是会像其他那些用户相关节点一样，接收用户 ID 的，对吧？
或许你会认为自己是有创造力的，并且很有艺术感的人。请容我向你介绍，这一全新的折磨方式。
世界是瞬息万变的，没人说过所有东西都必须一成不变。也没人说过一致性和可预测性是优秀开发经验和成功项目的关键。也许真的有人说过，但我们也不一定要听他们的不是？
我们的任务是通过让代码库中的一个函数拥有一点点的可变性，来毁掉别人的美好一天。
举例来说，一个验证函数，数据验证通过会返回 True，验证失败则会返回一条失败信息。那么，如果这个函数会在数据正确的情况下返回 False 或未定义，你的同事大概就要再多写几个情况来处理你的返回了，这岂不美哉。
当然，你也可以在所有函数中都接受不同形状的参数。拿上面这张梗图为例，让一些函数接受用户 ID，另一些则在完全可以只用用户 ID 的情况下接受整个用户对象。或许你还可以找到些接受用户电邮地址的方法？接手你代码的家伙要面临的可就是地狱啊。
你甚至还可以再添加一点惊喜的元素，让一切都变得不可预测起来。管他的一致性，随机性万岁！当然，别再惦记着整个代码库了，一个文件一个文件地改过去多好。工程师有什么意思，不如做个艺术家快活自在！我相信你的开发者同僚们一定会打心底地恨着你。但这又有什么用呢，你已早早领先了。
把代码复制黏贴得到处都是
图译：我的代码库：把其他文件里的同一段代码复制黏贴到不同文件里
等你这么做了之后，我相信没人会想再和你共事了。
别把相同逻辑分散到不同的函数、类、组件里去。只复制黏贴你需要的那几行代码就够了。
毕竟，你的代码是完美且意义非凡的，所有人都要在项目中的不同部分重复看到很多遍才够。让你的代码发光发热吧！
但你也知道，这并不是你疯狂复制代码的原因。在一些更新中，系统会要求开发者们同时更改大量文件内容。如果测试范围不够，某些人可能会忘记删掉一两次的重复逻辑，并不得不开始第二次甚至是第三次的更新。还有什么是比在成千上百的文件中搜索重复代码更有趣的事呢？你的同事们一定会乐在其中的。
记得我说过好的缩写很难并且非常浪费时间吗？那么我们为什么不直接在需要的地方把代码复制过去呢？不然的话，你大概还要再花时间向别人解释你为啥要不断复制你之前的代码。我相信你，你一定可以做到的！
总结
很明显，这篇文章就是图一乐。请千万不要尝试我在文中描述的这些操作，这可不是什么可以“赌五毛”的小玩笑。
请一定要在实践中按相反的来：
-
代码中的命名保持清晰明了
-
代码要简单易懂
-
保持整洁的项目结构
-
记得使用常量以及可预测的界面
-
在保持代码清晰的同时分割相同逻辑
以及最重要的一点，善待你的同事们！
在开发社区中流传着这样一个说法，在你编写代码时，永远要像是被连环杀人犯接手你的代码一样。你可不想被一个连环杀人犯盯上，对不对？
而我则认为，你更应该在写代码时，想象着如果下一个接手这份代码的人是你自己，你会怎么想。
在你编程时，请一定要问问自己，“如果我早就不记得这些程序是干什么的时候，我会乐意看到这些代码吗？”
原文链接：
https://tsh.io/blog/bad-coding-practices/
本文文字及图片出自 InfoQ
共有 1 条讨论