我尽可能在函数名中使用描述性语言。这有时会导致函数名过长，例如GetActionFromTypeName或GetSelectedActionType等二三十个字符的函数名。那么函数名何时变得太长难以管理（而不是编译器过长）？
函数名字太长的标准是什么？
52
- C. Ross
9
22当你使用没有代码自动补全功能的编辑器时，函数名会变得太长。 - schnaader
2当我使用vim时，我的函数名称的长度相同。 - C. Ross
1好的，vim用户也倾向于能够写得很快。总的来说，程序员往往具有更好的打字技能...但是使用代码自动完成仍然更好。 - schnaader
4这个问题的意义是什么？当程序员觉得函数名称太长时，函数名就太长了。我们无法告诉你，作为编写代码的程序员，是否觉得名称太长。 - jalf
6@jalf，问一些“有趣”的问题没关系，对吧？这是其中之一，此外和其他人一起思考它也很有好处。 - C. Ross
显示剩余4条评论
27个回答
1
当开发人员忘记参数的描述性质时（假设有意义的参数和变量名称），函数和方法名称开始变得过长。例如：
my $template = HTML::Template->new( filename => 'home.html');
$template->param( title => 'Home Page' );
$html = $template->output;
即使您不了解 Perl，也从不听说过 HTML::Template，它的工作方式是透明的。
我太经常看到一些人诱惑性地将那个output方法命名为像RenderHTMLViewFromTemplateObject这样的东西。 如果所有使用的库都有这种命名约定，那么我就无法简单地跟随这发生了什么。
- Sinan Ünür
1
我认为这对于公共名称尤其重要 - 它们不应过长，但太长是非常主观的。总是有一个更长和描述性的名称比太短的名称更好。
对于私有方法，即使非常长的名称，在我看来也不是问题。
- tanascius
1
有时候在Oracle SQL和PL/SQL的许多情况下，30个字符的限制感觉像是一个可怕的限制，但仔细思考后，它让我们多次思考如何命名事物，以便稍后阅读代码的人能够快速理解。
如果我们不能充分描述表、视图、函数、过程、包等的目的，而不使用过多的缩写，那么它只需要更多的思考，也许需要额外的抽象层来将相关的事物组合在一起。
如果我们不能充分描述表、视图、函数、过程、包等的目的，而不使用过多的缩写，那么它只需要更多的思考，也许需要额外的抽象层来将相关的事物组合在一起。
- Jeffrey Kemp
0
尽力避免主观性：
当名称长度接近你典型行长的1/3时，就已经有些过长了。当名称占据一半甚至更多时，就太长了。如果变量名占据整行，每行只能写一条语句是相当麻烦的。
此外，大多数IDE都支持自动补全（从而使程序员无需完整地手动输入变量名），所以我认为更重要的是尽早使变量名尽可能唯一。
- mlibby
0
如果编译器对变量名有一些限制，通常是64个或128个字符之间。过去，32个字符也很流行。如果它们有限制，它们通常只使用前n个字符并忽略其余部分。
一般规则是函数名提供了一个非常简短的描述，说明它在做什么。这样的描述大多数都应该容易地适应于32个字符以内。（使用驼峰命名法来分隔单词）。由于现在大多数的IDE都提供了代码自动完成功能，所以使用错误的函数名称确实很少见。但是，请确保大多数函数名称的前8个字符不同，以使自己更容易。例如，避免像DateCalculationAddMonth、DateCalculationAddWeek、DateCalculationAddYear和DateCalculationAddDay这样的函数名称。请使用AddMonthDateCalculation、AddWeekDateCalculation、AddYearDateCalculation和AddDayDateCalculation。（顺便说一下，这些只是愚蠢的例子，但我希望您能理解我的意思。）
实际上，将您的函数添加到单独的类中可能会更好。以上面愚蠢的例子为例，您可以创建一个名为DateCalculation的类，并向该类添加四个（静态/类）函数（AddMonth、AddWeek、AddYear和AddDay）。基本上，当您有许多类似的函数需要分组在一起时，这种方法会更加有用，否则它们的名称会非常冗长。- Wim ten Brink
0
在我看来，如果函数名中有连词，比如"When"、"And"、"Then"等等，那么它就太长了。遵循单一职责原则应该允许函数名足够长以便描述清楚，但也要足够短以免过于烦琐。
- Kaz Dragon
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接