Question

在过去的几周里，我看到有些人使用非常长的名字来表示方法或类（50个字符），这通常是在提高可读性的前提下，我认为像这样的长名字是一个指标如果我们需要这么长的名字，我们试图在方法类中做很多或者太多，但是我想知道你们对它的看法。

一个例子是：

getNumberOfSkinCareEligibleItemsWithinTransaction

Answer 1

当存在同样表达方法行为的较短名称时，Java或任何其他语言的名称太长。

Answer 2

减少方法名称长度的一些技巧：

如果您的整个计划，课程或模块是关于'护肤品'，您可以放弃皮肤护理。例如，如果您的班级被称为SkinCareUtils，这会带你到getNumberOfEligibleItemsWithinTransaction
您可以将中的更改为中的，getNumberOfEligibleItemsInTransaction

您可以将交易更改为Tx，从而转到getNumberOfEligibleItemsInTx。

或者，如果方法接受Transaction类型的参数，则可以完全删除InTx：getNumberOfEligibleItems

您可以按计数更改numberOf：getEligibleItemsCount

现在这很合理。它缩短了60％。

Answer 3

只是为了改变，一个非主观的答案：65536个字符。

A.java:1：字符串“xxxxxxxxxxxxxxxxxxxx ...”的UTF8表示太长对于常量池

- ）

Answer 4

我同意所有人的观点：方法名称不应太长。我确实想添加一个例外：

但是，JUnit测试方法的名称可能很长，应该类似于句子。

为什么？

因为在其他代码中没有调用它们。
因为它们被用作测试名称。
因为它们可以写成描述要求的句子。（例如，使用AgileDox）

示例：

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

有关此想法的更多信息，请参阅“Behavior Driven Design”。

Answer 5

上下文“......内部交易”应该是显而易见的。这就是面向对象的全部内容。

该方法是类的一部分。如果班级不是指“交易” - 并且如果它不能让你不必一直说“内部交易”，那么你就会遇到问题。

Answer 6

我倾向于使用 ha句规则来命名：

 Seven syllable class names 
 five for variables
 seven for method and other names

这些是最大名称的经验法则。我只有在提高可读性时才会违反此规定。像recalculateMortgageInterest（currentRate，quoteSet ...）这样的东西比recalculateMortgageInterestRate或recalculateMortgageInterestRateFromSet更好，因为它涉及的速率和一组引号应该从嵌入式文档（如javadoc或.NET等价物）中非常清楚。

注意：不是真正的ha句，因为它是7-5-7而不是5-7-5。但我还是喜欢称之为ha句。

Answer 7

Java有一种鼓励长名称的文化，也许是因为IDE具有良好的自动完成功能。

This site表示JRE中最长的类名是InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState，长度为92个字符。

至于最长的方法名称，我找到了这个supportsDataDefinitionAndDataManipulationTransactions，即52个字符。

Answer 8

当小人物会这么做时，不要使用长词。

我不认为你的“方法名称长度与方法长度成正比”的论文确实有用。

以您给出的示例为例：“getNumberOfSkinCareEligibleItemsWithinTransaction”。这听起来像是它只做一件事：它计算交易中属于特定类别的项目数。当然，如果没有看到该方法的实际代码，我无法判断，但这听起来对我来说是一个很好的方法。

另一方面，我已经看到很多方法都有非常简短的名称，可以用来做很多工作，比如“processSale”或者流行的“doStuff”。

我认为很难给出一个关于方法名称长度的严格规则，但目标应该是：足够长的时间来传达函数的功能，足够短以便可读。在这个例子中，我认为“getSkinCareCount”可能已经足够了。问题是你需要区分什么。如果您有一个功能可以计算交易中符合护肤条件的物品，而另一个功能可以计算符合皮肤护理条件的物品，那么“内部交易”会增加价值。但如果在交易之外谈论这些项目并不意味着什么，那么用这些多余的信息来扼杀名称就没有意义了。

二，我认为假设任何可管理长度的名称将告诉你除了最琐碎的案例之外的所有函数的确切含义，这是非常不现实的。一个现实的目标是创建一个名称，为读者提供线索，以后可以记住。就像，如果我试图找到计算我们需要消耗多少反物质以达到翘曲速度的代码，如果我查看函数名称并查看“calibrateTransporter”，“firePhasers”和“calcAntimatterBurn”，很明显前两个不是它，但第三个可能是。如果我检查并发现那确实是我正在寻找的那个，那么很容易记住，当我明天回来再研究这个问题时。那太好了。

三个相似的长名称比短名称更令人困惑。如果我有两个名为“calcSalesmanPay”和“calcGeekPay”的函数，我可以快速猜一眼哪个。但如果他们被称为“calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation”和“calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation”，我必须研究名称，看看哪个是哪个。在这种情况下，名称中的额外信息可能会适得其反。它将半秒钟的思考变成了30秒的思考。

Answer 9

按照您希望的方式设计界面，并使实现匹配。

例如，也许我会把它写成

getTransaction().getItems(SKIN_CARE).getEligible().size()

或使用Java 8流：

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

Answer 10

我的规则如下：如果名称太长以至于它必须出现在它自己的一行上，那么它太长了。（实际上，这意味着我很少超过20个字符。）

这是基于研究表明可见垂直代码行的数量与编码速度/有效性正相关。如果类/方法名称开始显着损害它，它们太长了。

在声明方法/类的位置添加注释，如果您需要详细说明它的用途，请让IDE将其带到那里。

Answer 11

方法本身的长度可能是一个更好的指标，表明它是否做得太多，甚至只能给你一个粗略的想法。你应该努力简洁，但描述性更重要。如果你不能用较短的名字表达相同的含义，那么名称本身可能没问题。

Answer 12

下次你打算写一个方法名时，只要想到下面的引用

"The man who is going to maintain your code is a phyco who knows where you stay"

Answer 13

该方法名称肯定太长了。当我阅读如此大小的方法名称时，我的思绪往往会徘徊。这就像读一个没有空格的句子。

就个人而言，我更喜欢尽可能少的方法。如果包和类名称可以传达意义，那么您将获得帮助。 如果班级的责任非常简洁，则不需要巨大的方法名称。我很好奇为什么会出现“内部交易”。

“getNumberOfSkinCareEligibleItemsWithinTransaction”可能变为：

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems（）;

然后在使用时，该方法可能看起来像“query.getNumEligibleItems（）”

Answer 14

如果较短的名称可以在整个程序或程序的重要部分提供更好的代码可读性，则变量名称太长。

如果较长的名称允许您传达有关值的更多信息。但是，如果名称太长，它将使代码混乱并降低理解其余代码的能力。这通常是通过引起换行并将其他代码行推离页面来实现的。

诀窍是确定哪个会提供更好的可读性。如果变量经常在短时间内使用或多次使用，最好给它一个简短的名称并使用注释澄清。读者可以轻松地参考评论。如果变量经常在整个程序中使用，通常作为参数或在其他复杂的操作中使用，最好减少名称，或使用首字母缩略词作为读者的提醒。如果它们忘记了含义，它们总是可以通过变量声明来引用注释。

这不是一个简单的权衡，因为你必须考虑代码阅读器可能试图理解的内容，并且还要考虑代码如何随着时间的推移而变化和增长。这就是为什么命名事情很难。

可读性是为什么使用i作为循环计数器而不是DescriptiveLoopCounterName是可接受的。因为这是变量的最常见用途，所以您可以花费最少的屏幕空间来解释它存在的原因。较长的名称只会浪费时间，因为要更难理解如何测试循环条件或索引到数组中。

另一方面，如果在复杂操作中很少使用函数或变量，例如传递给多参数函数调用，则可以给它一个过于描述的名称。

Answer 15

与任何其他语言一样：当它不再描述该功能执行的单个动作时。

Answer 16

我会说使用好答案的组合并且合理。

完全，清晰，可读地描述该方法的作用。

如果方法名称看起来太长 - 重构该方法以减少工作量。

Answer 17

当方法的名称换行到另一行并且对方法的调用是唯一的东西并且开始非常靠近边距时，它太长了。您必须考虑将要使用它的人的屏幕平均大小。

但是！如果名称似乎太长，那么它可能太长了。解决这个问题的方法是编写代码，使其处于上下文中，并且名称很短但在其他上下文中重复。这就像你可以用英语说“她”或“他”而不是某人的全名。

Answer 18

太久了，它太过于彻底地解释了这件事的内容。

例如，这些名称在功能上是等效的。

Java中的

：java.sql.SQLIntegrityConstraintViolationException

在Python / Django中：django.db.IntegrityError

问自己，在SQL / db包中，你能提出多少种类型的完整性错误？ ;）因此db.IntegrityError就足够了。

Answer 19

标识符名称超出Java编译器可以处理的长度时会过长。

Answer 20

这里有两种方式或观点：一种是方法名称有多长并不重要，只要描述方法正在做什么就是描述性的（Java最佳实践基本规则））。另一方面，我同意flybywire的帖子。我们应该使用我们的智能来尽可能地减少方法名称，但不要降低它的描述性。描述性更重要：）

Answer 21

如果名称太长：

阅读时间超过1秒
占用比为JVM分配的RAM更多的RAM
是荒谬的名字
如果一个较短的名字很有意义
如果它在您的IDE中包裹

老实说，这个名称只需要向开发人员传达其目的，将其作为公共API方法使用，或者在离开时必须维护代码。记住KISS（保持简单愚蠢）

Java方法名称何时太长？

21 个答案: