代码异味：函数名称中没有 AND

函数应该遵循单一职责原则——这意味着它应该只做一件事。所以，如果你的函数名包含“AND”，那就意味着你做的太多了。解决办法？删除“AND”，并将其拆分成多个单独的函数👍

// ❌ Bad
function teaAndSugar () {}

// ✅ Better
function tea () {}
function sugar () {}

单一职责原则（SRP）

每个模块都应该只有一个职责。这意味着两个独立的关注点/职责/任务应该始终在不同的模块中实现。

原理 Wiki：SRP

背后的理由是：

如果不遵守此规则，一个模块就会有多个任务。如果其中一个任务发生变化，则可能会影响到通常独立的另一个任务。因此，不相关的功能可能会中断。

当您遵循单一职责原则时，您将创建一个更加灵活和模块化的代码库。

非开发术语中的 SRP 优势

我们试着用非开发者的术语来解释一下。假设你是一名厨师，正在为你的厨房订购食材。两个卖家向你推荐他们的产品。卖家 A 告诉你，我们有你需要的所有食材，而且所有食材都为你混合好了。卖家 B 告诉你，我们有你需要的所有食材，但会单独出售给你。你会买哪一个？当然，卖家 A 的选择很不错，因为所有食材都是预先混合好的。但是你能做的菜谱非常有限，因为你只能做需要所有 3 种食材的菜谱。然而，选择卖家 B，你能做的菜谱是无穷无尽的。你可以制作甜点和咸味菜肴👩‍🍳

卖家A：

购买预先混合的配料会限制您只能使用需要所有 3 种材料的食谱。

function flourAndSugarAndEgg () {}

卖家B：

购买单独的食材可以消除限制，让您可以制作更多食谱🏆

function flour () {}

function sugar () {}

function egg () {}

可维护性效益

坚持这条规则的另一个好处是可维护性。刚开始的时候，把所有东西都整合起来可能看起来容易得多。但我保证，随着时间的推移，随着你添加更多功能或进行更改，一个包揽所有功能的单一函数会变得非常难以维护。

用非开发术语解释

让我们用另一个非开发术语来解释这一点。假设你是一个乐高爱好者，你给自己买了一套全新的乐高积木。你非常兴奋，打开了新套装，把所有的零件都倒进一个容器里。不幸的是，你下周有期末考试，所以你还没有时间去搭建它。几周后，你富有的阿姨又买了几套乐高积木。我提到你阿姨很有钱，因为我们都知道乐高积木贵得离谱😂。你又打开新套装，把它们倒进同一个容器里，认为这没什么大不了的。为了不被你富有的阿姨比下去，你富有的奶奶也想赢得你的爱，所以她给你买了更多的乐高积木。同样，你不认为这是什么大不了的事，你打开所有东西，把它们都倒进同一个容器里。好了，几周过去了，现在你准备好搭建你的乐高积木了。猜猜发生了什么？你现在正用头撞墙。因为所有积木都混放在一个容器里，你根本分不清哪个是哪个。不过，如果你把所有乐高积木都放在一个单独的容器里，就不会有这个问题了💩

这就是为什么一个函数应该只做一件事。当它做不止一件事的时候。现在看起来可能没有，但随着时间的推移和需求的变化，这个函数会变得臃肿，维护起来也会变得极其困难。

社区意见

@Skateside：另一个专业建议：函数名以动词开头。这样可以让你的意图更清晰，更容易解释——“这个函数泡茶，那个函数加糖。”

function makeTea() {}
function addSugar() {}

@sunnysingh.io：像 😝 这样的通用函数，getData()嗯……什么类型的数据？除非是顶级实用程序，否则我喜欢用更具体的格式，比如getUser()、getPost()等等。
@Mouadovicc :我更喜欢用drinkTeaanddrinkSugar代替 AND，在这种情况下用一个统一的词就是 drink

资源

感谢阅读❤
打个招呼！Instagram | Twitter | Facebook | Medium |博客

鏂囩珷鏉ユ簮锛�https://dev.to/samanthaming/code-smell-no-and-in-function-name-1g10