什么时候函数名太长？

【问题标题】：When is a function name too long?什么时候函数名太长？
【发布时间】：2009-06-19 12:12:22
【问题描述】：

如果可能的话，我会尽量用描述性来描述我的函数名称。这有时会导致函数名称在 20 到 30 个字符范围内，例如 GetActionFromTypeName 或 GetSelectedActionType。什么时候函数会变得太长而无法管理（对于编译器来说不会太长）？

【问题讨论】：

  • 当您必须使用没有代码完成的编辑器时，函数名称会变得太长。
  • 我使用vim时函数名的长度一样...
  • 嗯，vim 用户也往往能够写得很快。好的，程序员通常倾向于更好的打字技巧......但代码完成仍然更好。
  • 这个问题有什么意义？当程序员觉得函数名太长时，函数名就太长了。我们谁也不能告诉你，作为代码的程序员，你是否觉得这个名字太长了。
  • @jalf，问“有趣”的问题可以吗？这就是其中之一，而且与其他人一起思考是件好事。

标签： language-agnostic naming-conventions


【解决方案1】：

如果有更短但描述性的函数命名方式，则函数名称太长。

【讨论】：

  • 更具体地说，如果存在一个可以去掉而不引入歧义的单词，则名称太长。
  • 然而，缩短构成长函数名称的单词，例如使用 GetActionFromTypeName 而不是 GetActFromTypeName，MS 认为这是一种不好的做法
【解决方案2】：

当你不能在中间不呼吸的情况下大声朗读它们时=D

【讨论】：

    【解决方案3】：

    当函数名开始过度描述其功能或妨碍代码的可读性时，函数名就会太长。

    【讨论】：

    • 说得好。保持名称简洁明了，但仍具有描述性。
    【解决方案4】：
    1. 如果您必须向右滚动才能阅读。
    2. 描述正在做的 3 件或更多事情 - 它不应该做那么多事情。
    3. 你的老板认为它太长了。
    4. 它比代码本身更长。
    5. 它以 Get 开头，就像其他 500 个函数一样。
    6. 没有人愿意使用它。
    7. 还有另一个功能可以使用用户理解的较短名称来执行相同的操作。
    8. 可以缩短。

    【讨论】：

      【解决方案5】：

      当它不做它所说的一切时。 ;)

      【讨论】：

      • 是的； “代码完成”（至少第一版）中的史蒂夫·麦康奈尔同意。
      【解决方案6】：

      另一方面，TheFunctionNameBecomesTooLongWhenItBecomesTooHardToReadItAndUnderstandIt it_dependends_on_nameing_convention_how_hard_function_reading_is_sometimes_long_names_are_readable。

      【讨论】：

      • 我很确定我已经在 PHP 标准库中看到了上述两个函数。
      【解决方案7】：

      当你开始思考时:)

      【讨论】：

      • 我正要说什么时候你必须移动你的眼睛，但这几乎是一回事。
      • 很多阅读是 [几乎] 即时识别单词的形状，然后才有时间有意识地记录和思考它们。短短语也可以以同样的方式被理解，但长序列必须有意识地分解成它们的“部分”才能被理解。也就是说，按顺序阅读。对于不同的人，这个过程可能会有所不同，但会倾向于遵循在适应一种语言时所学的习惯。有了函数名，如果学会了一种具体的构造方法，读起来会越来越熟练，但还是会受到母语的限制。
      【解决方案8】：

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

      【讨论】：

        【解决方案9】：

        来自Code Complete（第 1 版，第 188 页）

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

        这是我见过的关于变量名称长度合理指南的唯一实证讨论。其他一切都取决于意见和舒适度。

        【讨论】：

        • 我不认为这个经验性讨论是直接适用的，因为它不涉及函数名，只是变量名。
        • 同意，变量名和函数名用法完全不同。
        【解决方案10】：

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

        【讨论】：

          【解决方案11】：

          这可能有点跑题了，但是当您专门询问 function 名称指南（而不是说，方法）时，我想我会引用 Linus Torvalds 的命名（尽管它更多指的是变量，但仍然 - 原则成立）。

          第 3 章：命名

          C 是一种斯巴达语言，因此应该 你的名字是。与 Modula-2 和 Pascal 程序员，C 程序员做 不要使用可爱的名字，比如 ThisVariableIsATemporaryCounter。交流电 程序员会调用那个变量 “tmp”，写起来容易得多， 而且不是最困难的 明白。

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

          【讨论】：

            【解决方案12】：

            我想说的是，当您在提及他们时发现自己发现他们的名字缩写时。当人们开始在名称中描述前置/后置/参数条件或提供有关实现的提示时，我也发现它太多了。 （如getVersionInformationFormTheDatabase() 或doSomethingWithoutCheckingFooFirst()）

            【讨论】：

              【解决方案13】：

              在我看来，函数名称应该与描述其用途所需的长度一样长。如果你认为函数名太长，那可能说明它试图做的事情太多，应该重构。

              【讨论】：

                【解决方案14】：

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

                【讨论】：

                  【解决方案15】：

                  只要这些函数确实按照其名称所暗示的那样工作，并且您不打算输入代码高尔夫，我认为这是一件好事。

                  【讨论】：

                    【解决方案16】：

                    我认为您应该更多地担心函数名称何时太短或描述性不够。只要您的函数执行其名称所描述的内容（以及其名称所描述的一切），它就是名副其实的。我经常编写具有长名称的函数，例如 getPropertyNameArrayFromObject（尽管我倾向于下划线而不是驼峰式），可以称为 getObjPropArr 或其他名称，但不会像描述性那样。我倾向于远离缩写词，因为当您处理其他事情并返回代码时，它们会变得模棱两可。

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

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

                    【讨论】：

                      【解决方案17】：

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

                      我倾向于发现如果我不能用几句话来概括它，那么设计就有问题（来自 Code Complete 的旁白）。

                      所以虽然我对FindArticlesWithoutTitles 很满意，但我可能会对FindArticlesWithoutTitlesThenApplyDefaultStyles 感到厌恶。这是错误的；要么名称太专业，没有描述它的实际功能（没有文章的标题通常需要固定样式，所以这将是FixArticleStyles）或者它应该是两个功能：FindArticlesWithoutTitles/ApplyDefaultStyles。

                      另外：频率与它有很大关系。如果经常使用，我希望它简短，以减少代码的眩光；冗长的重复名称使代码难看，打字也很痛苦。如果我总是找到FindArticlesWithoutTitles，我可能会根据适当的上下文缩短为FindNoTitles，或者如果我没有其他文章查找功能，甚至可能只是FindArticles。

                      【讨论】：

                      • 请注意，在此示例中，使用完全描述性标题命名函数的习惯是发现设计缺陷的原因。通过发现正确的名称应该是“FindArticlesWithoutTitlesThenApplyDefaultStyles”，您实际上发现该函数做得太多了。缩写名称的趋势会掩盖这一事实。让你的名字具有描述性。如果描述太长，请缩短功能，而不是名称。
                      • 但我认为这并不是那么简单，一个人的冗长是另一个人的极简主义。我有一个执行以下操作的函数：打开一个文件，读取文件的每一行，验证，与数据库行进行比较，并且任何不在数据库中的内容都存储在 C# 字典中。这听起来像是很多东西，但是将其拆分为几个函数会使其更难阅读。将它包装在一个名为 LoadSymbolsFile 的函数中会更简单，这在类的上下文中是有意义的。该函数是私有的并且被调用一次。
                      【解决方案18】：

                      当它包含从上下文中显而易见的信息（例如，incrementInteger(int x)、long longID）、无用的（例如，ObsoleteIncrementer、RobertsCarFactory）、难以理解的（例如，TheFunctionThatRobertWorkedOnLastWeekButDidntFinish）、数字（例如，id1、id2、id3 ) 或以其他方式无助于理解或包含代码异味。请注意，即使上述名称的某些部分应该被删减，您可能需要用有用的信息填充它们以保持它们的唯一性并使其易于理解，例如 id1 的 person_id、id2 的雇主 ID 等。

                      【讨论】：

                        【解决方案19】：

                        函数名称太长，如果使用较短的名称可以节省您的工作量。

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

                        【讨论】：

                          【解决方案20】：

                          我认为这对于公共名称尤其重要——它们不应该太长，但是太长有多长是非常主观的。总是有一个更长的描述性的名字比一个太短的名字更好。
                          对于私有方法，我认为即使是很长的名称也没有问题。

                          【讨论】：

                            【解决方案21】：

                            有时，在 Oracle SQL 和 PL/SQL 的许多上下文中，30 个字符的限制感觉像是一个可怕的限制，但回想起来，它让我们多次努力思考如何命名事物，以便人们快速理解它们稍后阅读代码。

                            如果我们不能在不使用过多缩写的情况下使用 30 个字符来充分描述表、视图、函数、过程、包等的用途，那么它只需要更多的思考，或许还需要额外的抽象层将相关的事物组合在一起。

                            【讨论】：

                              【解决方案22】：

                              问自己一个更有趣的问题：为什么我们要让函数名变长？这是为了描述函数的作用。好吧，我提交这个假设：

                              函数名中必要的描述量与可用的类型信息量成反比。

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

                              public <A> A id(A a);

                              ...你认为它有什么作用？类型信息告诉你你需要知道的一切。除非有副作用和异常，这个函数只能做一件事。

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

                              【讨论】：

                                【解决方案23】：

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

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

                                即使您不懂 Perl 并且从未听说过 HTML::Template，它的作用也是透明的。

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

                                【讨论】：

                                  【解决方案24】：

                                  尽量避免主观性：

                                  当名称大约是您的典型行长的 1/3 时，您就是在拉伸它。在 1/2 的行长处，你已经走得太远了。当名称占据整行时，每行一个语句会变得非常困难。

                                  除此之外，大多数 IDE 都支持完成（从而使程序员不必完全输入大多数名称），所以在我看来，更重要的事情是确保名称尽可能唯一可能。

                                  【讨论】：

                                    【解决方案25】：

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

                                    保持代码可维护，改用 cmets。

                                    【讨论】：

                                      【解决方案26】：

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

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

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

                                      【讨论】：

                                        【解决方案27】：

                                        IMO，当它有一个连词时，它太长了。 “When”、“And”、“Then”……诸如此类。遵循“单一职责规则”应该允许函数名称足够长以具有描述性，并且足够短而不会令人讨厌。

                                        【讨论】：

                                          猜你喜欢
                                          • 2010-10-03
                                          • 1970-01-01
                                          • 2011-01-14
                                          • 2021-11-12
                                          • 1970-01-01
                                          • 1970-01-01
                                          • 1970-01-01
                                          • 2011-09-20
                                          • 2019-09-04
                                          相关资源
                                          最近更新 更多
                                          热门标签
                                          Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode