函数名称何时太长？

Question

在可能的情况下，我尝试使用我的函数名称进行描述。这偶尔会导致20到30个字符范围内的函数名称，例如“GetActionFromTypeName”或“GetSelectedActionType”。在什么时候，函数管理的时间太长（编译器不会太长）？

Answer 1

如果有一个更简短但又描述性的方法来命名该函数，那么函数名称太长了。

Answer 2

当你在中间没有呼吸时不能大声朗读它们= D

Answer 3

当函数名称开始过度描述它的作用时，或者当它阻碍代码的可读性时，函数名称太长。

Answer 4

当它没有做所有它说它做的时候。 ;）

Answer 5

1. 如果您必须向右滚动才能阅读。
2. 描述了3个或更多的事情 - 它不应该做那么多事情。
3. 你的老板认为太长了。
4. 它比代码本身更长。
5. 它以Get开头，就像500个其他功能一样。
6. 没有人想要使用它。
7. 还有另一个函数可以使用用户理解的较短名称来执行相同的操作。
8. 可以缩短。

Answer 6

TheFunctionNameBecomesTooLongWhenItBecomesTooHardToReadItAndUnderstandIt，另一方面 it_dependends_on_nameing_convention_how_hard_function_reading_is_sometimes_long_names_are_readable。

Answer 7

从Code Complete（第1版，第188页）

“Gorla，Benander和Benander发现，当变量的名称平均为10到16个字符（1990）时，调试COBOL程序所需的工作量最小化。名称平均为8到20个字符的程序几乎同样易于调试。 “

这是对我所见过的变量名称长度的合理指导方针的唯一实证讨论。其他一切都取决于意见和安慰。

Answer 8

我不认为方法名称可能太长，只要它是描述性的。如果方法名称超过40个字符，我将看到我是否可以用更少的单词表达相同的含义。如果不是，为了清楚起见，我将与长名称一起生活。

Answer 9

当你开始思考它时：）

Answer 10

如果函数名称“太长”，那么函数本身也可能太长并且责任太大。许多聪明的程序员说一个函数应该只做一件事而且只做一件事。一个函数的名称必须很长才能准确地描述它的作用，这可能是重构为multiple smaller and simpler private functions的一个很好的候选者，因此会缩短名称。

Answer 11

这可能有点偏离主题，但正如你专门询问功能名称指南（而不是方法），我想我会引用Linus Torvalds的命名（虽然它更多指变量，但仍然 - 原则保持不变。

  

第3章：命名

     

C是斯巴达语，因此应该如此   你的命名是。与Modula-2和。不同   Pascal程序员，C程序员   不要用像可爱的名字   ThisVariableIsATemporaryCounter。一个C.   程序员会调用该变量   “tmp”，写起来容易得多，   而且至少更难   理解。

简短的描述性名称适用于简短的特定功能......这与代码重用相得益彰。

Answer 12

我会说当你发现自己在引用它们时发现它们的名字的缩写。当人们开始描述名称中的前/后/参数条件或给出实现提示时，我也发现它太多了。 （例如getVersionInformationFormTheDatabase()或doSomethingWithoutCheckingFooFirst()）

Answer 13

在我看来，函数名称应该与描述其目的所需的时间完全相同。如果你认为函数的名称太长，那么这可能表明它试图做太多事情，应该重构。

Answer 14

只要这些功能实际上按照他们的名字所暗示的那样做，并且你不打算输入代码高尔夫球，我认为这是件好事。

Answer 15

当它包含从上下文中显而易见的信息（例如，incrementInteger（int x），long longID），无用（例如，ObsoleteIncrementer，RobertsCarFactory），难以理解（例如，TheFunctionThatRobertWorkedOnLastWeekButDidntFinish），数字（例如，id1，id2，id3） ）或以其他方式无助于理解或包含代码气味。请注意，即使上面某些部分的名称应该被修剪，你可能需要用有用的信息填充它们以保持它们的独特性并使它们易于理解，如id1的person_id，id2等的employer_id等。

Answer 16

函数名称太长，以免您使用较短的函数名称。

我们通常选择描述性功能名称的原因是因为它节省了我们的工作。 （通过使其更容易理解和维护代码）。所以从逻辑上讲，你不应该给你的函数名称太长，以至于它花费你额外的时间（例如，使代码更难阅读）

Answer 17

啊，一个没有答案的问题！

我倾向于发现如果我不能用几句话来封装它，那么设计就会有所改进（从代码完成中描述）。

因此，虽然我对FindArticlesWithoutTitles感到满意，但我可能会对FindArticlesWithoutTitlesThenApplyDefaultStyles感到厌恶。这是错的;要么名称太技术性而没有描述它的实际功能（没有文章的标题通常需要修复样式，所以这应该是FixArticleStyles）或它应该是两个函数：FindArticlesWithoutTitles/ApplyDefaultStyles。

另外：频率与它有很大关系。如果它经常使用，我希望它很短，以减少代码的眩光;长重复的名称会使代码难以阅读并且难以输入。如果我总是找到FindArticlesWithoutTitles我可能会缩短到FindNoTitles，具体取决于相应的上下文，如果我没有其他文章找到函数，甚至可能只是FindArticles。

Answer 18

当开发人员忘记参数的描述性质时（假设有意义的参数和变量名称），函数和方法名称开始变得太长。例如：

 my $template = HTML::Template->new( filename => 'home.html'); 
 $template->param( title => 'Home Page' );
 $html = $template->output;

即使您不知道Perl并且从未听说过HTML::Template，

仍然是透明的。

我经常看到将output方法命名为RenderHTMLViewFromTemplateObject的诱惑。如果所有使用的库都有这样的命名约定，那么我就无法理解正在发生的事情。

Answer 19

我认为您应该更多地担心函数名称何时太短或者描述性不够。只要您的函数执行其名称描述的内容（以及其名称所描述的所有内容），它就会得到很好的命名。我经常使用像getPropertyNameArrayFromObject这样的长名称来编写函数（虽然我倾向于使用下划线而不是camelize），这可以被称为getObjPropArr或其他东西，但不会像描述那样。我倾向于远离缩写，因为当你开始做其他事情并回到代码时，它们变得模棱两可。

另一方面，考虑许多内置的PHP函数，例如stricmp，它应该按照caseInsensitiveStringComparison的名称命名。

在某些情况下，我故意编写非常简短的功能名称。有时我只想要一个简短的JavaScript函数作为快捷方式。例如，我通常将$（id）别名为document.getElementById（id），因为我厌倦了输入它。

Answer 20

我认为这对于公众名称尤其重要 - 它们不应该太长，但是多长时间是非常主观的。总是有一个更长的描述性名称，而不是一个太短的名字 对于私人方法，即使很长的名字在我看来也没问题。

Answer 21

恕我直言，功能描述更为重要。 IDE有助于避免拼写错误或类似的麻烦。我认为有时可以使用缩写，只要它们在代码中是一致的（同一个东西没有不同的缩写，也不是两个不同东西的缩写。

Answer 22

如果编译器对变量名称有一些限制，它通常是64或128个字符或介于两者之间。在过去，32个字符也很受欢迎。如果他们确实有限制，他们通常只需要前n个字符而忽略其余的字符。

一般规则是函数名称提供了它正在做什么的非常简短的描述。大多数此类描述应该很容易适合32个字符。 （使用CamelCase来分隔单词。）由于大多数IDE现在提供代码完成，因此使用函数名称进行错误确实很少见。但是通过确保大多数功能与前8个字符相互不同，确保自己更容易。应避免使用DateCalculationAddMonth，DateCalculationAddWeek，DateCalculationAddYear和DateCalculationAddDay之类的东西。使用AddMonthDateCalculation，AddWeekDateCalculation，AddYearDateCalculation和AddDayDateCalculation。 （顺便说一句，这些都是愚蠢的例子，但我希望你理解我的漂移。）

实际上，将函数添加（分组）到单独的类可能更好。使用上面的愚蠢示例，您可以创建一个DateCalculation类，并向该类添加四个（静态/类）函数（AddMonth，AddWeek，AddYear和AddDay）。基本上，当你有许多类似的函数时，这会更有用，如果不将它们组合在不同的类中，它们都会有很长的名字。

Answer 23

方法名称可能非常长，具体取决于语言（Maximum Method Name Length）。在某些时候，您将使用该函数或方法并为函数名称键入一个句子似乎是不必要的。

保持代码可维护，改为使用注释。

Answer 24

尽量避免主观性：

当名称大约是典型线长的1/3时，那么你就是拉伸它。在1/2线长度你太远了。当名字占据整行时，每行一条声明变得非常艰难。

除此之外，大多数IDE支持完成（从而节省程序员实际上完全输入大多数名称），因此在我看来，更重要的是确保名称尽可能独特。可能的。

Answer 25

IMO，当它有一个连接时，它太长了。 “当”，“和”，“然后”，......这样的事情。遵循一个责任规则应该允许足够长的描述性和足够短的功能名称，以免令人讨厌。

Answer 26

问自己一个更有趣的问题：为什么我们将函数名称设置得很长？这是为了描述函数的作用。好吧，我提出这个假设：

  

函数名称中所需的描述量与可用的类型信息量成反比。

为了说明这一点，如果你看到这样的函数......

public <A> A id(A a);

......你觉得它会怎样？类型信息告诉您需要知道的一切。除了副作用和异常，这个功能只能做一件事。

当然，您可能正在使用一种允许不受约束的副作用的语言，因此该功能可以写入文件。但如果它确实那么它的类型就是谎言。使用在类型中声明效果的语言，可以使用非常简洁的名称，而不会丢失任何描述性。

Answer 27

有时在Oracle SQL和PL / SQL的许多上下文中，30个字符的限制感觉就像一个可怕的限制，但经过反思，它已经让我们多次思考如何命名事物以便他们很快理解它们稍后阅读代码。

如果我们无法使用30个字符来充分描述表，视图，函数，过程，包等的用途而不使用过多的缩写，那么只需要更多的思考，也许还需要额外的抽象层。把相关的事情集体在一起。