最近，我写了与实现相关的名称，并提供了一些示例，这些示例由于方法名称与主体之间的紧密关系而导致方法名称不正确。
有一会儿，我们有以下代码：
boolean isComplexOrUnreadableWithTests() { return (complex || unreadable) && tests.exist();
}只是为了提醒您上下文：应该确定我们是否可以进行重构：
if (code.isComplexOrUnreadableWithTests()) {doRefactoring(code);
} 最近，我告诉您该名称是错误的，因为它与实现有直接关系。 但是，这不是唯一的问题。 在方法名称中使用连接词是一个标志，表明我们找不到正确的名称，而仅列出了我们已经完成的所有已知操作。 此列表与实现或逻辑相关都无关紧要。
关于实现还是逻辑？
如果我想将isComplexOrUnvisibleWithTests（）方法的名称更改为：
boolean isJustifiedAndPossible() { return (complex || unreadable) && tests.exist();
}会更好吗？ 现在不是基于逻辑的名称吗？
我们有关于合理性的部分：
(complex || unreadable)关于重构的可能性：
tests.exist()当实现更改时，我们不需要更改名称，对吗？ 好吧，不完全是。 让我解释。
我们没有将面向实现的名称更改为面向逻辑的名称。 我们只是混合了。 我们使用已知的词（可能来自领域）将实现隐藏在这两个术语后面。 但是，通过阅读方法的名称，我们仍然知道问题的答案如何。 而且我们仍然不知道最初的问题是什么。
当结果为布尔值时，我假设所问的问题类似于“是吗？” 。 以给出的名称，我们仍然没有关于“某物”的任何信息。
同样，该方法的名称没有我们想象的那么持久。 如果在开发过程中，我们决定从代码中删除tests.exist（）部分，则需要在名称中反映此更改并将其更改为：
boolean isJustified() { return complex || unreadable;
}此外，您可能会注意到，现在该名称可以准确告诉您问题所在。
但是，初始更改需要在方法主体内部及其名称上进行更改。
遗失词
除了方法本身的名称之外，在某些情况下，我们使用已知术语来描述新事物，但不命名，可能会导致更多问题：
- 交流 -每次谈论时都会解释该术语。 您只想让另一个人对相同上下文的理解。 用一个单独的短语来表达“ The Something”会更好吗？
例如，您可能想像一下如果您不能使用设计模式的名称，与其他开发人员的对话将是什么样子。 这些对话肯定会更长，并且会带来更高的误解风险。
缺少术语会导致完全相同的问题。 - 复制 –有人可能会问相同的问题，但是由于缺少适当的用语，他们不能百分百确定问题是否真的相同，是否有相同的意图。 在这种情况下，他们有机会选择一种更简单的方法，只编写可以给他们答案的代码。
- 提出相同的问题 -缺少术语意味着当我们想提出相同的问题时，很难找到此代码。 为什么？ 因为我们不知道要寻找什么。 或者我们可能知道，但是代码本身无法表达意图，我们正在寻找的内容与编写的内容之间可能没有关系。
如何发现问题？
嗯，这并不总是像给定示例中那样容易。 但是，有两件事可以帮助您确定名称是好还是需要改进：
- 结合语 –我们讨论了单一职责原则 ，因此在编写代码时应用此原则很重要。 并没有出现不遵循SRP的征兆吗？ 当我们使用“和”或“或”之类的词时，我们通常谈论的不止一件事。
只要在变量，方法或类的名称中发现连词，就应将其视为警告。 有很大的机会需要改进。 - 正文更改会导致名称更改 -如果代码更改不能更改功能背后的全部原理，但仍需要更改方法/类的名称，则表明该名称可能未表示真实意图。
在这种情况下，我们应该重新考虑名称并加以改进。
你好，我的名字是…
我知道有时候找到一个好名字要比编写实现难得多，但这并不意味着我们不应该尝试。 使名称尽可能具有描述性和准确性符合我们自己的利益。 这将节省我们将来的时间。
翻译自: https://www.javacodegeeks.com/2016/06/conjunctions-we-hate.html
)
