把命名变成猜谜游戏

糟糕的编码习惯

让我们用一些简单的东西来热身。作为一个好的开始，**请在变量或函数名称中添加一些额外的缩写。 **

我知道，我知道 – 使所有名称尽可能具有描述性是一种很好的做法，对吗？像handleFormSubmit，getUserConfiguration或parseCustomerInformation。但我们不是来做好工作的。

**对于糟糕的结果，请始终尽可能缩短和缩写名称，这样下一个处理您代码的开发人员将不得不猜测您在想什么。 **

像handleBtnClick、getConfig或 之parseInfo类的名称是很好的随意示例。它们不会透露太多函数在做什么，但您仍然可以在代码审查期间运行它。而不必要的缩写，如btn 、func 、config或cb使其更难以理解。

你可以用变量名做更多的事情！有未确认的用户列表？不要叫它uncofirmedUsers，只是命名它users。下一个开发人员将不得不阅读返回变量的整个代码以了解其中的内容。没有为那个可怜的灵魂打折的产品，因为产品的名字仍然是真实的和足够的。

为了给名字添加一点香料，您可以随时玩转外壳，我保证同事们会为此讨厌您的胆量。不是创建例如：良好实践建议的readXmlDocument （缩写应该像常规单词一样格式化），您可以创建一种readXMLDocument 方法，该方法将要求其他开发人员仔细查看并更仔细地阅读名称以完全理解它。

当然，所有这些疯狂都可以在代码审查期间停止，但您的工作是为之奋斗。也许是因为你懒得修复它，或者是因为你需要维护你的麻烦制造者角色。无论如何，请记住，您始终可以承诺在下一个拉取请求时更改它，希望每个人都会原谅并忘记您的罪（并且可能他们会这样做）。

编写非常复杂的代码

糟糕的编码习惯 复杂的代码

在这里，您将有机会证明您是软件开发领域的 Rick Sanchez。

**你只需要以一种比它应该的方式更复杂的方式来编写你的代码。 **

也许您可以通过创建一个接受五个参数的方法来找到一些泛化，允许您在两个地方重用三行代码？也许您可以通过使用巧妙的三重嵌套三元运算符将三行代码减少为一行？你的想象力是极限！

当然，这会使应用程序更难阅读和维护，但这可能是您同事的问题，对吗？优秀的！

所以试一试，写一段代码来证明你是一个真正的黑客。我建议你使用链式函数、嵌套条件语句、过度膨胀的设计模式和巧妙的单行代码，它们使用你所写语言的小众时髦特性。因为Date.now()如果你能用更神秘的东西做同样的事情，+new Date()为什么还要写呢？ 我敢肯定，当您的项目同事花时间试图了解代码中发生的事情时，他们会感谢您。

请记住：代码越是过度设计和早期优化，你就越会让你的同事为之奋斗。使用reduce函数可以获得 10分，进行递归调用可以获得 100 分。到项目结束时，这将使您成为真正的专业编码员，恭喜！

引入过多依赖

糟糕的代码实践依赖

我知道上述技术很难通过代码审查。但是，如果您是使用 JS 或 PHP 编写的 Web 开发人员，则几乎每个文件的顶部都有许多 import/use 子句。许多开发人员在代码审查期间不会检查它，因为他们直接滚动到他们认为的重要部分。

**这就是为什么依赖项是一个很好的地方，您可以邀请恐怖分子让自己在代码中感到舒适。 **

想象一下，你UserSubscriptions在 React 中calculateTimeToSubscriptionEnd有一些视图。使用辅助函数创建文件。伟大的。现在你应该把这个文件放在哪里？在存储与订阅或付款相关的所有域逻辑的单独目录中？噗，当然不是。最好把它放在你刚刚创建的视图旁边！

这是提前考虑，因为当您最终制作管理面板（以及Subscriptions 那里的视图）时，没有什么能阻止您从用户视图导入辅助函数。可能没有人会注意到它，因为几乎没有人检查进口清单。通过这种方式，您将耦合两个不相关的模块，并使那些试图更改某些内容或重构代码的开发人员陷入困境。相信我，没有什么比结构非常糟糕的项目更让开发人员疯狂了。

我听到你说，“这看起来不像是一个巨大的障碍”。经验不足的开发人员可能在很长一段时间内都无法解决这个问题。他们会与他们发现的混乱作斗争，认为保持现状很重要。当一个新的开发人员试图理解应用程序结构时，它每次都会伤害他们。当开发人员更新或删除与该功能相关的内容时，它会更加触发。一个伤害每个人的小混乱，直到某个英雄来解决它。也许有一天它甚至可以是你？

使相同的功能表现不同

糟糕的编码实践功能

你认为自己是一个有创造力的艺术灵魂吗？这是你最喜欢的新折磨方法。

世界是不可预测的，没有人说过一切都必须以同样的方式运作。此外，从来没有人说过一致性和可预测性是出色的开发人员体验或成功项目的关键。好吧，很多人都这么说，但我们今天不听他们的，好吗？

我们在这里破坏某人的一天是通过使代码库中的类似函数表现得有点不同。

例如，您可能有一些验证函数，当数据有效时返回true ，当某些事情不太正确时返回带有错误消息的字符串。如果您添加的下一个验证器在传递的值正确时返回false或undefined怎么办？这将破坏某人编写非常干净的表单处理的计划。好的…

您还可以在每个函数中接受完全不同形状的参数。就像上面的表情包一样。让我们中的一些人接受用户 ID，但其他人接受整个用户的反对（即使他们只需要 ID）。或者也许您会找到一种方法来接受用户的电子邮件？对于下一个必须处理该代码的开发人员来说，这将是一个巨大的杀戮。

我敢打赌，您可以想出更好的方法来让其他开发人员大吃一惊，那么为什么不让一切变得不可预测呢。降低一致性！随机性万岁！此外，永远不要考虑项目代码库的大局，专注于为每个单独的文件添加一点乐趣。换句话说：不要成为工程师，而要成为艺术家！我向你保证，其他开发人员会发自内心地讨厌它。但这显然是因为你太超前了。

到处复制代码

糟糕的编程实践 meme squirtle

做到这一点，没有人会想再次使用您的代码。

**不要将任何通用逻辑分离到不同的函数、类或组件中。只需在文件之间复制您需要的行。 **

毕竟，您的代码是完美的并且非常重要，所以让我们让每个人在整个项目中多次看到它。让它闪耀！

但是你看，这并不是复制代码的唯一理由。如果有任何更新，它将迫使开发人员一次对许多文件进行更改。更好的是，有人可能（并且可能会，如果项目中没有足够的测试）错过复制逻辑的一次或多次出现，并被迫进行第二次甚至第三次修复。还有什么比在项目代码库的数百个文件中搜索相同的代码更有趣的呢？我打赌你的同事会喜欢它。

请记住，进行良好的抽象既困难又耗时，因此您应该始终跳过它并在需要的地方复制代码。您的代码审查员会理解这一点。如果没有，那么您可以花时间解释为什么制作更多宝贵代码的副本很重要。你能行，我相信你！

撒旦在召唤，所以我要结束了

糟糕的编程习惯

• 在你的代码中保持描述性和清晰的命名，
• 让你的代码简单易懂，
• 保持干净的项目结构，
• 永远不要忘记编写一致且可预测的接口，
• 在不失去代码清晰度的情况下，尽可能分离公共逻辑。

开发社区中有一种说法，您应该始终像在您是连环杀手之后的下一个开发人员一样编写代码。你不想让杀手讨厌你，是吗？我不喜欢这种态度。

下次你主动编码时，问问自己：“在我早已忘记它们是做什么的之后，我会很高兴看到这些行吗？”