在Clean Code中，作者举了一个例子

assertExpectedEqualsActual(expected, actual)

与

assertEquals(expected, actual)

前者声称更为清晰，因为它消除了记住论据去向以及由此引起的潜在滥用的必要性。但是，我从未在任何代码中看到前者命名方案的示例，并且一直都在看到后者。正如作者所断言的，为什么编码人员不采用前者，如果后者比后者更清晰？

因为它的打字更多，阅读更多

最简单的原因是人们喜欢打字少，而编码信息意味着打字更多。阅读时，即使我熟悉参数的顺序，每次都必须阅读整个内容。即使不熟悉参数的顺序...

许多开发人员使用IDE

IDE通常提供一种机制，可以通过悬停或通过键盘快捷键查看给定方法的文档。因此，参数名称始终在手边。

编码参数会引入重复和耦合

参数名称应该已经记录了它们的含义。通过在方法名称中写出名称，我们也在方法签名中复制了该信息。我们还在方法名称和参数之间创建耦合。说expected，actual并让我们的用户感到困惑。从assertEquals(expected, actual)转到assertEquals(planned, real)不需要使用函数更改客户端代码。从assertExpectedEqualsActual(expected, actual)到assertPlannedEqualsReal(planned, real)意味着对API的重大更改。或者我们不更改方法名称，这很快就会造成混乱。

使用类型而不是模棱两可的参数

真正的问题是我们有模棱两可的参数，因为它们是同一类型，所以很容易切换。我们可以改用类型系统和编译器来强制执行正确的顺序：

class Expected<T> {
    private T value;
    Expected(T value) { this.value = value; }
    static Expected<T> is(T value) { return new Expected<T>(value); }
}

class Actual<T> {
    private T value;
    Actual(T value) { this.value = value; }
    static Actual<T> is(T value) { return new Actual<T>(value); }
}

static assertEquals(Expected<T> expected, Actual<T> actual) { /* ... */ }

// How it is used
assertEquals(Expected.is(10), Actual.is(x));

然后可以在编译器级别强制执行此操作，并确保您无法将它们向后退。从不同的角度出发，这基本上就是Hamcrest库用于测试的功能。

您询问有关编程的长期争论。多少详细程度是好？作为一个普遍的答案，开发人员发现命名参数的额外冗长是不值得的。

详尽并不总是意味着更加清晰。考虑

copyFromSourceStreamToDestinationStreamWithoutBlocking(fileStreamFromChoosePreferredOutputDialog, heuristicallyDecidedSourceFileHandle)

与

copy(output, source)

两者都包含相同的错误，但是实际上我们是否更容易找到该错误？一般而言，最简单的调试方法是，当所有事物都非常简洁时，除了少数具有bug的事物之外，这些事物的详细程度足以告诉您出了什么问题。

添加冗长的词已有很长的历史。例如，有一种普遍不受欢迎的“ 匈牙利表示法 ”，为我们提供了像这样的奇妙名称lpszName。在一般的程序员人群中，这通常被抛在一边。但是，在成员变量名称（如mName或m_Name或name_）中添加字符在某些圈子中仍然很受欢迎。其他人则完全放弃了。我碰巧在一个物理模拟代码库上工作，该代码库的编码样式文档要求任何返回向量的函数都必须在函数调用（getPositionECEF）中指定向量的框架。

您可能对Apple流行的某些语言感兴趣。Objective-C包含参数名称作为函数签名的一部分（函数[atm withdrawFundsFrom: account usingPin: userProvidedPin]在文档中以表示withdrawFundsFrom:usingPin:。即函数的名称）。Swift做出了一系列类似的决定，要求您将参数名称放入函数调用（greet(person: "Bob", day: "Tuesday")）中。

“清洁代码”的作者指出了一个合理的问题，但是他建议的解决方案相当微不足道。通常，有更好的方法来改进不清楚的方法名称。

他是正确的assertEquals（从xUnit样式的单元测试库中得出）并不清楚哪个参数是期望的，哪个参数是实际的。这也咬了我！许多单元测试库已经注意到了这个问题，并引入了其他语法，例如：

actual.Should().Be(expected);

或类似。当然比清楚得多，assertEquals但也比更好assertExpectedEqualsActual。而且它也更具可组合性。

您正在尝试使Scylla和Charybdis之间的道路更加清晰，避免不必要的冗长（也称为无目的漫游）以及过分简短（也称为神秘简洁）。

因此，我们必须查看要评估的接口，这是一种使两个对象相等的调试断言的方法。

1. 它可能还考虑其他功能和名称吗？
   不，所以名称本身很清楚。
2. 类型有意义吗？
   不，所以让我们忽略它们。你已经做到了吗？好。
3. 它的论证对称吗？
   几乎在出错时，该消息会将每个参数表示形式放到自己的位置。

因此，让我们看看这种微小的差异是否有意义，而现有的强规范并没有涵盖这些差异。

如果无意间交换了论点，目标听众是否会感到不便？
不，开发人员还会获得堆栈跟踪，并且无论如何都必须仔细检查源代码才能修复该错误。
即使没有完整的堆栈跟踪，断言位置也可以解决该问题。而且即使丢失了该消息，并且从哪条消息中看不出来，它最多也会使可能性加倍。

参数顺序是否遵循约定？
似乎是这样。尽管这似乎充其量是一个薄弱的约定。

因此，这种差异看起来微不足道，并且参数顺序已被足够强的约定所覆盖，即将其编码为函数名的任何努力都具有负效用。

通常，它不会增加任何逻辑上的清晰度。

比较“添加”到“ AddFirstArgumentToSecondArgument”。

例如，如果需要重载，则添加三个值。什么更有意义？

另一个带有三个参数的“添加”？

要么

“ AddFirstAndSecondAndThirdArgument”？

方法的名称应传达其逻辑含义。它应该告诉它做什么。从微观层面上讲，它采取了什么步骤并没有使读者更容易。如果需要，参数名称将提供其他详细信息。如果您仍然需要更多详细信息，那么代码将在那里。

我想添加其他答案提示的其他内容，但我认为并未明确提及：

@puck说：“仍然不能保证函数名称中提到的第一个参数确实是第一个参数。”

@cbojar说“使用类型而不是模棱两可的参数”

问题在于编程语言无法理解名称：它们只是被视为不透明的原子符号。因此，就像代码注释一样，函数的名称与其实际操作方式之间不一定存在任何关联。

比较assertExpectedEqualsActual(foo, bar)一些替代品（从本页面和其他地方），如：

# Putting the arguments in a labelled structure
assertEquals({expected: foo, actual: bar})

# Using a keyword arguments language feature
assertEquals(expected=foo, actual=bar)

# Giving the arguments different types, forcing us to wrap them
assertEquals(Expected(foo), Actual(bar))

# Breaking the symmetry and attaching the code to one of the arguments
bar.Should().Be(foo)

这些都比冗长的名称具有更多的结构，这使该语言看起来不透明。函数的定义和用法也取决于此结构，因此它不会与实现的工作不同步（例如名称或注释可以）。

当我遇到或预见到这样的问题时，在沮丧地大喊大叫计算机之前，我先花一点时间问一下，责怪这台机器是否“公平”。换句话说，机器是否获得了足够的信息以区分我想要的东西和我想要的东西？

像这样的呼叫与assertEqual(expected, actual)一样有意义assertEqual(actual, expected)，因此我们很容易将它们混在一起，并且机器可以向前犁并做错事。如果我们assertExpectedEqualsActual改用它，则可能使我们减少犯错的可能性，但不会为机器提供更多信息（它无法理解英语，并且名称的选择不应影响语义）。

使“结构化”方法更可取的原因，例如关键字参数，带标签的字段，不同的类型等，是额外的信息也是机器可读的，因此我们可以让机器发现不正确的用法并帮助我们正确地做事。的assertEqual情况下，是不是太糟糕，因为唯一的问题是不准确的消息。一个更险恶的例子可能是String replace(String old, String new, String content)，它很容易混淆，String replace(String content, String old, String new)其含义却大不相同。一个简单的补救方法是采用一对[old, new]，这会使错误立即触发错误（即使没有类型）。

请注意，即使使用类型，我们也可能发现自己没有“告诉机器我们想要的东西”。例如，称为“字符串型编程”的反模式将所有数据视为字符串，这使得很容易混淆参数（像这种情况），忘记执行某些步骤（例如转义），意外破坏不变式（例如制作无法解析的JSON），等等。

这也与“布尔盲”有关，在布尔盲中，我们在代码的一部分中计算一堆布尔（或数字等），但是当尝试在另一部分中使用它们时，尚不清楚它们实际代表什么。我们将它们混合在一起，以此类推。将其与例如具有描述性名称（例如LOGGING_DISABLED而不是false）的不同枚举进行比较，如果将它们混合在一起会导致错误消息。

因为它无需记住参数的去向

真的吗 仍然不能保证函数名称中第一个提到的参数确实是第一个参数。因此最好查找它（或让您的IDE这样做）并使用合理的名称，而不是盲目地依赖一个相当愚蠢的名称。

如果您阅读了代码，则应该很容易地看到按原样命名参数时会发生什么。copy(source, destination)比诸如此类的东西更容易理解copyFromTheFirstLocationToTheSecondLocation(placeA, placeB)。

正如作者所断言的，为什么编码人员不采用前者，如果后者比后者更清晰？

因为对不同的样式有不同的观点，所以您可以找到x篇相反的其他文章的作者。您会发疯，试图跟随某人在某处写的所有内容;-)

我同意将参数名称编码为函数名称可以使函数的编写和使用更加直观。

copyFromSourceToDestination( // "...ahh yes, the source directory goes first"

忘记函数和Shell命令中参数的顺序很容易，因此许多程序员都依赖IDE功能或函数引用。名称中描述的参数将是这种依赖的有效解决方案。

但是，一旦写入，对参数的描述将对下一个必须读取该语句的程序员来说是多余的，因为在大多数情况下，将使用命名变量。

copy(sourceDir, destinationDir); // "...makes sense"

这种简洁的风格将赢得大多数程序员的青睐，我个人认为它更易于阅读。

编辑：正如@Blrfl所指出的，编码参数毕竟不是那么“直观”，因为您首先需要记住函数的名称。这需要查找函数引用或从IDE获得帮助，而它们可能仍会提供参数排序信息。