Java方法名称何时过长？[关闭]

在过去的几周里，我见过有些人在方法或类上使用非常长的名称（50个字符），这通常是在提高可读性的前提下进行的，我认为这样的长名称可以表明我们如果需要这么长的名称，尝试在方法类中做很多事情或做太多事情，但是我想知道你们对此有何看法。

一个例子是：

getNumberOfSkinCareEligibleItemsWithinTransaction

如果存在较短的名称（可以平等地传达方法的行为），则Java或任何其他语言的名称都太长。

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

1. 如果您的整个程序，课程或模块是关于“皮肤护理项目”的，则可以放弃皮肤护理。例如，如果您的班级名为，则将您SkinCareUtils带到getNumberOfEligibleItemsWithinTransaction

2. 您可以在中更改为，getNumberOfEligibleItemsInTransaction

3. 您可以将Transaction更改为Tx，从而可以转到getNumberOfEligibleItemsInTx。

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

5. 您通过计数更改numberOf： getEligibleItemsCount

现在，这是非常合理的。而且缩短了60％。

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

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

;-)

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

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

为什么？

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

例：

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

有关此想法的更多信息，请参见“ 行为驱动设计 ”。

上下文“ ... WithinTransaction”应该很明显。这就是面向对象的全部意义。

该方法是类的一部分。如果该类不是“ Transaction”的意思，并且它不能使您不必一直说“ WithinTransaction”，那么您就会遇到问题。

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

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

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

注意：不是真正的句，因为它是7-5-7而不是5-7-5。但是我仍然更喜欢将其称为haiku。

Java具有鼓励长名的文化，这可能是因为IDE具有良好的自动补全功能。

这个站点说JRE中最长的类名InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState是92个字符长。

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

如果小字句会用的话，切勿使用长字。

我认为您的“方法名称的长度与方法的长度成正比”的论点并没有真正成立。

以您提供的示例为例：“ getNumberOfSkinCareEligibleItemsWithinTransaction”。在我看来，这听起来像是一件事：它计算属于某个类别的交易中的项目数。当然，我不能不看该方法的实际代码就做出判断，但这听起来对我来说是一个好方法。

另一方面，我看到了很多方法的名称非常简短，这些名称可以做很多工作，例如“ processSale”或流行的“ doStuff”。

我认为很难对方法名称的长度给出严格的规定，但目标应该是：足够长以传达函数的作用，足够短以使可读。在此示例中，我认为“ getSkinCareCount”可能就足够了。问题是您需要区分什么。如果您有一个功能可以计算交易中符合皮肤护理项目的功能，而另一个功能可以计算其他事物中符合皮肤护理项目的功能，那么“ withinTransactions”会增加价值。但是，如果在交易之外谈论这些项目并不意味着什么，那么用这些多余的信息来弄乱名字就毫无意义。

第二，我认为假设任何可管理长度的名称都能告诉您该函数在除最琐碎的情况以外的所有情况中的确切功能是不现实的。一个现实的目标是创建一个给读者一个线索的名称，并在以后记住该名称。就像，如果我试图找到计算达到扭曲速度需要消耗多少反物质的代码，如果我查看函数名称并看到“ calibrateTransporter”，“ firePhasers”和“ calcAntimatterBurn”，那么很明显前两个不是，但第三个可能是。如果我检查发现确实是我要寻找的那个，那么很容易记住，当我明天回来为这个问题做更多工作时。够了

三个相似的长名称比短名称更容易混淆。如果我有两个名为“ calcSalesmanPay”和“ calcGeekPay”的函数，那么我可以快速猜出哪个函数。但是，如果将它们分别称为“ calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation”和“ calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation”，则我必须研究这些名称以了解哪个是哪个。在这种情况下，名称中的额外信息可能适得其反。它将半秒钟的思考变为30秒钟的思考。

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

例如，也许我会写成

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

或使用Java 8流：

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

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

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

在声明方法/类的位置添加注释，如果您想对其进行详细说明，请让IDE带您到那里。

方法本身的长度可能更好地指示了它是否做得太多，即使这样也只能给您一个大概的想法。您应该为简洁而努力，但描述性更重要。如果您不能用较短的名称传达相同的含义，则名称本身可能还可以。

下次要写方法名称时，请考虑一下波纹管引号

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

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

就我个人而言，我希望方法中的单词尽可能少。如果包和类名可以传达含义，则将为您提供帮助。如果该类的职责非常简洁，则无需使用巨大的方法名称。我很好奇为什么“ WithinTransaction”在那里。

“ getNumberOfSkinCareEligibleItemsWithinTransaction”可能变为：

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

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

如果较短的名称将使整个程序或程序的重要部分具有更好的代码可读性，则变量名太长。

如果使用更长的名称，则可以传达有关值的更多信息。但是，如果名称太长，则会使代码混乱，并降低理解其余代码的能力。这通常是通过引起换行并将其他代码行推离页面而发生的。

诀窍是确定哪种将提供更好的可读性。如果该变量经常或在较短的空间中多次使用，则最好给它起一个短名称并使用注释来说明。读者可以轻松参考该评论。如果在整个程序中经常使用该变量，通常将其用作参数或在其他复杂的操作中使用，则最好精简名称或使用缩写词来提醒读者。如果忘记了含义，他们总是可以通过变量声明引用注释。

这并非易事，因为您必须考虑代码阅读器可能试图理解的内容，并且还要考虑代码随着时间的变化和增长的方式。这就是为什么很难命名的原因。

可读性是为什么可以将i用作循环计数器而不是DescriptiveLoopCounterName的原因。因为这是变量的最常用用法，所以您可以花费最少的屏幕空间来解释其存在的原因。较长的名称只会使您更难理解测试循环条件或索引数组的方式，从而浪费时间。

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

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

我会说结合好答案并做到合理。

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

如果方法名称似乎太长，请重构该方法以减少操作。

当方法的名称换行到另一行并且对该方法的调用是该行上唯一的事情并且开始时非常接近边距时，太长了。您必须考虑将要使用该屏幕的人的平均屏幕尺寸。

但！如果名称看起来太长，则可能太长。解决该问题的方法是以这样一种方式编写代码，即您位于上下文中，并且名称简短但在其他上下文中重复。这就像您可以用英语说“她”或“他”而不是某人的全名一样。

太含蓄地解释事情的实质已经太久了。

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

在Java中： java.sql.SQLIntegrityConstraintViolationException

在Python / Django中： django.db.IntegrityError

问问自己，在SQL / db程序包中，您还能想到多少种类型的完整性错误？;）因此db.IntegrityError就足够了。

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

这里有两种方法或观点：一种是方法名称有多长真的无关紧要，只要它能尽可能描述性地描述方法的作用即可（Java最佳实践的基本规则）。另一方面，我同意flybywire的帖子。我们应该利用我们的智慧来尝试尽可能减少方法名称，但又不要减少其描述性。描述性更重要:)

名称太长，如果：

• 花费超过1秒的时间来阅读
• 占用的RAM比分配给JVM的RAM多
• 是荒唐的名字吗
• 如果一个简短的名字很合理
• 如果它在您的IDE中环绕

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