这五种糟糕的代码实践，程序员要学会规避.docxVIP

这五种糟糕的代码实践，程序员要学会规避 1、将变量命名变成解谜游戏 图译：Parsimony 代指什么：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 列表。两个毫不相关的模块搅在一起，别人再想修改或重构你的代码就得费好大的功夫。相信我，开发者们最最憎恶的莫过于是结构稀烂的项目。 你说什么？“这还不够混乱”？小菜鸟程序员们很可能在短时间内都不会动你的代码，他们会在你创造的一团乱麻中苦苦挣扎，想着保险起见还是保持原样最好。而每当有新开发者尝试理解你的项目结构，都会带来新一轮的折磨，当开发中更新或者删除了什