Java方法名称何时太长？
在过去的几个星期里，我看到一些人使用真正的长名称作为Method或Class（50个字符），这通常是在提高可读性的前提下，我认为像这样一个长名字是我们如果我们需要如此长的名字，试图在方法类中做很多或太多的事情，但是我想知道你们对此有什么看法。
一个例子是：
getNumberOfSkinCareEligibleItemsWithinTransaction Java或其他语言中的名称太长，因为较短的名称同时表示方法的行为。
一些减less方法名称长度的技术：
-
如果你的整个程序，课程或模块都是关于“护肤品”的话，你可以放下护肤品。 例如，如果你的类叫做
SkinCareUtils，那么你可以使用getNumberOfEligibleItemsWithinTransaction -
你可以在里面改变，
getNumberOfEligibleItemsInTransaction -
您可以将事务更改为Tx，这会使您获得
getNumberOfEligibleItemsInTx。 -
或者，如果方法接受一个types为
Transaction的参数，则可以完全删除InTx：getNumberOfEligibleItems -
您通过count更改numberOf：
getEligibleItemsCount
现在这是非常合理的。 它缩短了60％。
只是为了改变，一个非主观的答案：65536个字符。
A.java:1：string“xxxxxxxxxxxxxxxxxxxx …”的UTF8表示对于常量池太长
😉
我同意大家：方法名称不应该太长。 我想添加一个例外：
但是，JUnittesting方法的名称可能很长，应该类似句子。
为什么？
- 因为他们没有在其他代码中调用。
- 因为它们被用作testing名称。
- 因为他们可以写成描述需求的句子。 （例如，使用AgileDox ）
例：
@Test public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() { ... }
有关此想法的更多信息，请参阅“ 行为驱动devise ”。
上下文“… WithinTransaction”应该是显而易见的。 这就是面向对象的全部内容。
该方法是一个类的一部分。 如果课程不意味着“交易” – 如果它不能让您不必一直说“WithinTransaction”，那么您就遇到了问题。
我倾向于使用ha句规则的名字：
Seven syllable class names five for variables seven for method and other names
这些是最大名称的经验法则。 我只有在提高可读性时才违反这个规定。 像recalculateMortgageInterest（currentRate，quoteSet …）比recalculateMortgageInterestRate或recalculateMortgageInterestRateFromSet更好，因为它涉及率和一组引用应该是像javadoc或.NET等效的embedded式文档非常清楚。
注意：不是真正的ha句，因为它是7-5-7而不是5-7-5。 但我更喜欢称它为ha句。
Java有一个鼓励长名称的文化，也许是因为IDE具有良好的自动完成function。
这个网站说，在JRE最长的类名是InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState这是92个字符长。
至于最长的方法名称，我发现这个supportsDataDefinitionAndDataManipulationTransactions ，它是52个字符。
当一个小个子会做时，千万别用一个长长的词。
我不认为你的方法名长度与方法长度成正比。
以你给的例子：“getNumberOfSkinCareEligibleItemsWithinTransaction”。 这听起来对我来说只是一件事：它logging了交易中属于某个类别的项目数量。 当然，如果没有看到方法的实际代码，我不能判断，但这听起来像是一个很好的方法。
另一方面，我已经看到很多方法都是非常简短的名字，可以做很多工作，比如“processSale”或者是stream行的“doStuff”。
我认为对方法名称长度做一个严格的规则是很难的，但是目标应该是：足够长的时间来传达函数的function，足够短以便可读。 在这个例子中，我认为“getSkinCareCount”可能已经足够了。 问题是你需要区分。 如果您有一项function可以计算交易中符合条件的护肤项目，另一项function可以按照其他方式计算符合护肤条件的项目，则“withinTransactions”会增加价值。 但是，如果在交易之外谈论这样的事情并不意味着什么，那么用这些多余的信息就没有意义了。
二，我认为假定一个可控的长度的名字能够准确地告诉你函数的function是什么，除了最微不足道的情况外，是不切实际的。 一个现实的目标是创造一个给读者一个线索的名字，这个名字可以在以后被记住。 就像，如果我试图find代码来计算我们需要消耗多less反物质来达到扭曲速度，如果我看看函数名称，并看到“calibrateTransporter”，“firePhasers”和“calcAntimatterBurn”，这是非常清楚的前两个不是，而是第三个可能。 如果我检查并发现那确实是我正在寻找的那个，那么很容易记住，当我明天再回来再处理这个问题的时候。 这很好。
三个相似的长名字比短名称更令人困惑。 如果我有两个叫做“calcSalesmanPay”和“calcGeekPay”的函数，我可以很快地猜出一下。 但如果他们被称为“calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation”和“calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation”，我必须研究名称，看哪个是哪个。 在这种情况下，名字中的额外信息可能会适得其反。 半秒思考成一个30秒的想法。
我的规则如下：如果一个名字太长而不得不出现在它自己的一行上，那么它太长了。 （实际上，这意味着我很less超过20个字符。）
这是基于研究显示，可见的垂直代码行的数量与编码速度/有效性正相关。 如果类/方法名称开始显着伤害，它们太长了。
在声明方法/类的地方添加一个注释，并让IDE将您带到那里，如果您想要长时间描述它的用途。
以您希望的方式devise您的界面，并使实现相匹配。
例如，也许我会这样写
getTransaction().getItems(SKIN_CARE).getEligible().size()
或与Java 8stream：
getTransaction().getItems().stream() .filter(item -> item.getType() == SKIN_CARE) .filter(item -> item.isEligible()) .count();
方法本身的长度可能是一个更好的指标，它是否做得太多了，甚至只是给你一个粗略的想法。 你应该努力简洁，但描述性更重要。 如果你不能用较短的名字expression相同的意思，那么这个名字本身可能是好的。
那个方法的名字肯定太长了。 当我正在阅读这种大小的方法名称时，我的思维往往会徘徊。 这就像读一个没有空格的句子。
就个人而言，我更喜欢用尽可能less的方法。 如果包裹和class名可以传达意义，你会受到帮助。 如果class级的责任非常简洁 ，则不需要一个巨大的方法名称。 我很好奇为什么“WithinTransaction”在那里。
“getNumberOfSkinCareEligibleItemsWithinTransaction”可能变成：
com.mycompany.app.product.SkinCareQuery.getNumEligibleItems（）;
然后在使用时，该方法可能看起来像“query.getNumEligibleItems（）”
如果较短的名称可以使整个程序或程序的重要部分具有更好的代码可读性，那么variables名太长。
如果一个更长的名字可以让你传达更多关于价值的信息。 但是，如果某个名称太长，则会使代码混乱，并降低了理解其余代码的能力。 这通常是通过引起换行并将其他代码行从页面上移除而发生的。
诀窍是确定哪一个会提供更好的可读性。 如果variables在短时间内经常或多次被使用，最好给它一个简短的名字，并使用一个注释来澄清。 读者可以轻松地回顾评论。 如果variables在整个程序中经常使用，通常作为一个参数或者在其他复杂的操作中使用，那么最好减less名称，或者使用首字母缩写词作为提醒读者。 如果他们忘记了含义，他们总是可以通过variables声明引用一个注释。
这不是一个容易的交易，因为你必须考虑代码阅读器可能试图理解什么，并且考虑代码将如何随时间变化和增长。 这就是为什么命名是困难的。
可读性是为什么使用i作为循环计数器而不是DescriptiveLoopCounterName是可以接受的。 因为这是variables最常用的用法，所以可以花费最less量的屏幕空间来解释它存在的原因。 更长的名字只会让你更难理解如何testing循环条件或索引到数组中，从而浪费时间。
另一方面，如果函数或variables在复杂的操作中很less使用，例如传递给多参数函数调用，则可以给它一个过于描述的名称。
当你下次要写一个方法的名字时，只要想下面的报价
"The man who is going to maintain your code is a phyco who knows where you stay"
与其他语言一样：不再描述函数执行的单个动作。
我会说使用一个很好的答案的组合，是合理的。
完整，清晰，易读地描述该方法的function。
如果方法名称太长 – 重构方法做得less。
如果方法的名字换行，并且方法的调用是唯一的行并且开始非常接近边界，那么太长了。 你必须考虑到将要使用它的人的屏幕的平均大小。
但！ 如果这个名字太长，那么可能太长了。 解决这个问题的方法是编写代码，使其处于上下文中，名称短，但在其他上下文中重复。 这就像你可以用英语说“她”或“他”，而不是某人的全名。
当它过于详细地解释事情是什么时，这太长了。
例如，这些名称在function上是等同的。
在Java中： java.sql.SQLIntegrityConstraintViolationException
在Python / Django中： django.db.IntegrityError
在SQL / db包中问自己，你可以提出多less种types的完整性错误？ ;）因此db.IntegrityError就足够了。
如果标识符名称超过了Java编译器可以处理的时间，则名称太长。
这里有两种方法或观点：一是方法名称的长度真的没有关系，只要描述的方法尽可能描述（Java最佳实践基本规则）即可。 另一方面，我同意flybywire的post。 我们应该利用我们的智慧尽量减less方法的名称，但不能降低它的描述性。 描述性更重要:)
如果名字太长，
- 花费1秒以上的时间阅读
- 占用比为您的JVM分配更多的RAM
- 是荒谬的命名
- 如果一个较短的名字是完全合理的
- 如果它包装在您的IDE中
诚实地说，这个名字只需要将其目的传达给开发人员，将其作为公共API方法使用，或者在离开时必须维护代码。 只要记住KISS（保持简单愚蠢）
