什么时候 Java 方法名太长？

在过去的几周里，我看到一些家伙为一个方法或类使用了很长的名字(50个字符) ，这通常是在提高可读性的前提下，我的观点是，像这样的一个长名字是一个指示器，我们正在尝试做很多或太多的方法类，如果我们需要这样一个长名字，但我想知道你们怎么看它。

例如:

getNumberOfSkinCareEligibleItemsWithinTransaction
50485 次浏览
小开

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

该方法是类的一部分。如果这个类并不意味着“ Transaction”——如果它不能让你避免一直使用“ WithinTransaction”，那么你就有问题了。

小开
最佳答案

Java 或任何其他语言中的名称太长，如果存在一个较短的名称，同样表示方法的行为。

小开

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

这是基于研究表明，可见的代码垂直行的数量与编码速度/效率正相关。如果类/方法名开始严重影响这一点，那么它们就太长了。

在声明方法/类的地方添加一个注释，如果您想要详细描述它的用途，可以让 IDE 带您到那里。

小开

方法本身的长度可能是一个更好的指示器，它是否做得太多，即使这只是给你一个粗略的想法。您应该力求简洁，但描述性更为重要。如果你不能用一个短一点的名字来表达同样的意思，那么名字本身也许是可以的。

小开

与任何其他语言一样: 当它不再描述函数执行的单个操作时。

小开

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

小开

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

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

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

小开

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

“ xxxxxxxxxxxxxxxxxxxx...”的 UTF8表示形式太长 永恒的池

;-)

小开

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

  1. 如果您的整个程序、类或模块都是关于“护肤项目”的，那么您可以放弃护肤。例如，如果您的类名为 SkinCareUtils, 这就是 getNumberOfEligibleItemsWithinTransaction

  2. 你可以把 内心改成 进去，getNumberOfEligibleItemsInTransaction

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

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

  5. 通过计数改变数字: getEligibleItemsCount

现在这是非常合理的。它是60% 短。

小开

这里有两种方法或观点: 一种是，方法名称的长度并不重要，只要描述方法正在做什么就可以了(Java 最佳实践基本规则)。另一方面，我也同意这篇文章。我们应该使用我们的智能来尽可能地减少方法名，但是不要减少它的描述性。描述性更重要:)

小开

我倾向于使用 俳句规则来命名:

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

这些是最大化名字的经验法则。只有当它提高了可读性时，我才会违反这个规定。像 recalculateMORgageinterest (currentRate，quoteSet...)这样的东西比 recalculateMORgageInterestRate 或 recalculateMORgageInterestRateFromSet 要好，因为它涉及到利率和一组引号的事实应该从内嵌的文档(如 javadoc 或者。NET 等效。

注意: 不是一个真正的俳句，因为它是7-5-7而不是5-7-5。但我仍然喜欢称它为俳句。

小开

要我说，应该综合运用好的答案，并且要合理。

完整、清晰、可读地描述该方法的用途。

如果方法名太长——重构该方法以减少操作。

小开

如果一个名字太长:

  • 阅读需要超过1秒钟的时间
  • 占用的内存比为 JVM 分配的内存多
  • 有个很荒谬的名字
  • 如果短一点的名字更合适的话
  • 如果它在 IDE 中包装

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

小开

如果方法的名称换行到另一行上，并且对方法的调用是该行上唯一的内容，并且开始时非常接近边距，那么它就太长了。你必须考虑到将要使用它的人的平均屏幕尺寸。

但是！如果这个名字看起来太长，那么它可能就太长了。解决这个问题的方法是，以这样一种方式编写代码: 在一个上下文中，代码的名称很短，但在其他上下文中是重复的。这就像你可以用英语说“她”或“他”而不是某人的全名。

小开

如果一个小词就够了，就不要用长词。

我不认为你的“方法名称的长度与方法的长度成正比”的论点是站得住脚的。

举个例子: “ getNumberOfSkinCareEligibleItemsWithinTransaction”。在我看来，它只做一件事: 它计算属于某一类别的交易中的项目数量。当然，在没有看到该方法的实际代码之前，我不能做出判断，但是对我来说，这听起来是一个不错的方法。

另一方面，我见过许多方法，它们的名称非常简短，可以完成很多工作，比如“ processSales”或者一直流行的“ doStuff”。

我认为很难给出一个关于方法名长度的严格规则，但目标应该是: 长度足以表达函数的功能，短到可读。在这个例子中，我认为“ getSkinCareCount”可能已经足够了。问题是你需要区分什么。如果有一个函数计算事务中符合护肤条件的项目，另一个函数计算其他事务中符合护肤条件的项目，那么“ withinTransactions”会增加价值。但是，如果在交易之外谈论这些项目毫无意义，那么就没有必要在名称中添加这些多余的信息。

第二，我认为假设任何可管理长度的名称都能准确地告诉您函数在除了最琐碎的情况之外的所有情况下的作用是非常不现实的。一个现实的目标是创造一个名字，给读者一个线索，这可以记住以后。比如，如果我试图找到计算我们需要消耗多少反物质才能达到曲速的代码，如果我查看函数名称，看到“ CaliateTransport”，“ firePhaser”和“ calcAntimatterburn”，很明显前两个不是，但第三个可能是。如果我检查并且发现那确实是我正在寻找的那个，那么当我明天回来继续研究这个问题的时候，我会很容易记住这一点。这就够了。

第三，相似的长名称比短名称更容易混淆。如果有两个函数叫做“ calcSalesmanPay”和“ calcGeekPay”，我可以很快地猜出哪个是哪个。但是，如果它们被称为“ CalculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation”和“ CalculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation”，我就必须研究这些名字，看看哪个是哪个。在这种情况下，名称中的额外信息可能适得其反。它能把半秒钟的思考变成30秒钟的思考。

小开

这个方法名太长了。当我阅读如此大小的方法名称时，我的思维往往会走神。就像读一个没有空格的句子。

就我个人而言，我喜欢在方法上尽可能少说话。如果包和类名能够传达含义，那么您将得到帮助。如果班级的责任是很简洁的，不需要巨大的方法名。我很好奇为什么上面有“ WithinTransaction”。

“ getNumberOfSkinCareEligibleItemsWithinTransaction”可以变成:

Com.mycompany.app.product. SkinCareQuery.getNumEligibleItems () ;

然后在使用时，该方法可以看起来像“ query.getNumEligibleItems ()”

小开

当一个较短的名称可以使整个程序或程序的重要部分具有更好的代码可读性时，变量名就太长了。

如果较长的名称允许您传递有关值的更多信息。但是，如果一个名称太长，就会使代码杂乱无章，降低理解其余代码的能力。这通常是通过导致换行和将其他代码行推出页面来实现的。

关键在于决定哪种方式更具可读性。如果变量在很短的空间内经常或多次使用，最好给它一个简短的名称，并使用注释澄清。读者可以很容易地查阅评论。如果在整个程序中经常使用变量，经常作为参数或在其他复杂的操作中使用，那么最好缩减名称，或者使用缩略词提醒读者。如果它们忘记了注释的含义，它们总是可以通过变量声明引用注释。

这不是一个容易做出的权衡，因为您必须考虑代码读者可能试图理解什么，并且还要考虑代码将如何随着时间的推移而变化和增长。这就是为什么给东西命名很难。

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

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

小开

当你下次要写一个方法名的时候，只要想想下面的引号

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

我同意每个人的观点: 方法名称不应该太长，但是我想添加一个例外:

然而，JUnit 测试方法的名称可以很长，并且应该类似于句子。

为什么？

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

例如:

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

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

小开

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

比如，也许我会写成

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

或使用 Java8流:

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

太长的时间，太详细地解释了这件事是关于什么的。

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

Java 语言: java.sql.SQLIntegrityConstraintViolationException

在 Python/Django 中: django.db.IntegrityError

问问自己，在 SQL/db 包中，还能出现多少类型的完整性错误? ;) 因此 db.IntegrityError就足够了。


提交答案