函数可以太短吗？

每当我发现自己多次编写相同的逻辑时，我通常会将其粘贴在一个函数中，因此在我的应用程序中只有一个地方需要维护该逻辑。副作用是我有时会遇到一两个函数，例如：

function conditionMet(){
   return x == condition;
}

要么

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

这是偷懒还是不好的做法？我之所以只问是因为这会导致大量的函数调用需要非常小的逻辑。

呵呵，布朗先生，如果我能说服我遇到的所有开发人员将其功能保持在这种程度之内，请相信我，软件世界将是一个更好的地方！

1）您的代码可读性提高了十倍。

2）由于易于阅读，因此很容易弄清楚代码的过程。

3）干-不要重复自己-您对此非常满意！

4）可测试。与我们经常看到的那200条线方法相比，微小的功能要容易测试一百万倍。

哦，不必担心性能方面的“功能跳跃”。“发布”版本和编译器优化为我们很好地解决了这一问题，并且性能是系统设计中其他地方的99％。

这很懒吗？-恰恰相反！

这是不好的做法吗？- 绝对不。比起太常见的tar球或“上帝对象”，最好采用这种制造方法。

跟上我的工匠，继续努力；）

我要说的是，重构方法太短了：

• 它复制了原始操作，除使其成为方法外，没有其他目的：

例如：

boolean isNotValue() {
   return !isValue();
}

要么...

• 该代码仅使用一次，其意图一目了然。

例如：

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

这可能是有效的模式，但在此示例中，我只是内联了configureDialog（）方法，除非我打算覆盖它或在其他地方重用此代码。

函数可以太短吗？一般没有

实际上，唯一的方法可以确保：

1. 您已经找到设计中的所有类
2. 您的功能仅做一件事。

是使您的功能尽可能小。或者，换句话说，从函数中提取函数，直到无法提取为止。我称此为“提取直至删除”。

对此进行解释：函数是具有通过变量进行通信的功能块的作用域。类也是具有通过变量进行通信的功能块的作用域。因此，长函数始终可以用小方法替换为一个或多个类。

同样，一个足以使您从中提取另一个函数的函数在定义上做的不只是一件事情。因此，如果可以从另一个函数中提取一个函数，则应该提取该函数。

一些人担心这会导致功能的扩散。他们是对的。它会。这实际上是一件好事。很好，因为函数有名称。如果您在选择好名字时很小心，则这些功能可以充当指示其他人通过您的代码的路标。的确，在命名空间中，在命名类中的命名函数是确保读者不会迷路的最​​佳方法之一。

在cleancoders.com上的Clean Code第三章中有很多关于此的内容

哇，这些答案中的大多数都不是很有帮助。

不能编写任何以其定义为身份的函数。也就是说，如果函数名称只是用英语写出的函数的代码块，则不要将其写为函数。

考虑一下您的函数conditionMet和另一个函数addOne（请原谅我生锈的JavaScript）：

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMet是正确的概念定义；addOne是重言式。conditionMet之所以conditionMet有用，是因为您仅通过说“满足条件” 就不知道会发生什么，但是addOne如果您用英语阅读它，就会明白为什么很愚蠢：

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

为了爱任何可能仍然圣洁的事物，请不要编写重言式功能！

（并且出于同样的原因，不要在每一行代码中都写注释！）

我想说的是，如果您认为可以通过添加注释来改善某些代码的意图，则可以将代码提取到自己的方法中，而不是添加注释。无论代码多么小。

因此，例如，如果您的代码看起来像这样：

if x == 1 { ... } // is pixel on?

使它看起来像这样：

if pixelOn() { ... }

与

function pixelOn() { return x == 1; }

换句话说，这与方法的长度无关，而与自记录代码有关。

我认为这正是您想要做的。现在，该功能可能只有一两行，但随着时间的流逝它可能会增长。还有更多的函数调用，使您可以阅读函数调用并了解其中发生的情况。这使您的代码非常干（不要重复自己），这更易于维护。

我同意我所看到的所有其他帖子。这是很好的风格。

这种小的方法的开销可能为零，因为优化程序可以优化调用并内联代码。像这样的简单代码可以使优化器尽其所能。

为了清晰和简单起见，应编写代码。我试图将方法限制为以下两个角色之一：决策；或执行工作。这可能会生成一种方法。我做的越好，代码越好。

像这样的代码倾向于具有高内聚性和低耦合性，这是良好的编码实践。

编辑：关于方法名称的说明。使用方法名称，该名称指示什么方法不执行该操作。我发现verb_noun（_modifier）是一个很好的命名方案。这将提供类似于Find_Customer_ByName的名称，而不是Select_Customer_Using_NameIdx。修改方法时，第二种情况容易变得不正确。在第一种情况下，您可以换出整个Customer数据库实施。

将一行代码重构为一个函数似乎是多余的。可能会有例外情况，例如ver loooooong / comples line或expessions，但是除非我知道该功能将来会增长，否则我不会这样做。

您的第一个示例暗示了使用全局变量（可能会或可能不会提及代码中的其他问题），我将对其进行进一步的重构，并将这两个变量作为参数：

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

的conditionMet例子可能如果条件是长和重复，例如有用：

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

考虑一下：

一个简单的碰撞检测功能：

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

如果您一直在代码中编写“简单”的衬纸，最终可能会犯错。另外，一遍又一遍地写它真的很折磨。

不，这很少有问题。现在，如果有人觉得任何功能都不能超过一行代码（如果只是那么简单），那将是一个问题，并且在某种程度上是懒惰的，因为他们没有考虑什么是合适的。

我会说它们太短了，但这是我的主观意见。

因为：

• 如果仅使用一次或两次，就没有理由创建一个函数。跳到防御吸吮。特别是使用速度惊人的VS和C ++代码。
• 类概述。当您有成千上万的小功能时，它使我生气。当我可以查看类定义并快速查看它的功能而不是SetXToOne，SetYToVector3，MultiplyNumbers和100个setters / getter时，我感到很满意。
• 在大多数项目中，这些助手在一个重构阶段或两个重构阶段后变得无用，然后您执行“搜索全部”->删除操作以删除过时的代码，通常占代码的25％以上。

长的函数是不好的，但是短于3行并且仅执行1件事的函数同样是不好的恕我直言。

因此，我想只在以下情况下编写小型函数：

• 3行以上的代码
• 是否有初级开发人员可能会错过的东西（不知道）
• 进行额外验证
• 已使用或将使用至少3倍
• 简化常用界面
• 在下一次重构期间不会成为自重
• 有一些特殊的含义，例如模板专门化或其他
• 做一些隔离工作-const引用，影响可变参数，是否进行私有成员检索

我敢打赌，下一个开发人员（高级）将比记住所有SetXToOne函数有更好的事情要做。因此，无论哪种方式，它们很快都会变成自重。

我不喜欢这个例子。1，因为第i个通用名称。

conditionMet似乎不是通用的，所以代表特定条件吗？喜欢

isAdult () = { 
  age >= 18 
}

这样很好 这是语义上的差异，而

isAtLeast18 () { age >= 18; } 

对我不好。

也许它经常被使用，并且可以在以后进行更改：

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

也可以 多次使用它，如果需要的话，您只需要更改一个位置即可-也许明​​天就可以使用生奶油了。

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

不是原子的，应该给您一个不错的测试机会。

当然，如果您需要传递一个函数，则传递您喜欢的任何东西，然后编写看上去很傻的函数。

但是总的来说，我看到的函数太多了，而太短了。

最后一句话：有些函数看起来很恰当，因为它们写得太冗长了：

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

如果您看到它与

return (a < b); 

你不会有任何问题

localLessThan = (a < b); 

代替

localLessThan = lessThan (a, b); 

没有代码就没有代码！

保持简单，不要使事情复杂化。

这不是偷懒，它正在完成您的工作！

是的，可以使用短代码功能。如前面提到的答案，在使用“ getters”，“ setters”，“ accesors”的方法时非常常见。

有时，那些短的“ accesors”函数是虚拟的，因为当在子类中重写这些函数时，它们将具有更多的代码。

如果您不希望函数这么短，那么在许多函数（全局或方法）中，我通常使用“结果”变量（pascal样式）而不是直接返回，这在使用调试器时非常有用。

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

太短永远都不是问题。函数短的一些原因是：

可重用性

例如，如果您有一个函数（如set方法），则可以断言它以确保参数有效。必须在设置了变量的所有位置进行此检查。

可维护性

您可能会使用一些您认为将来可能会改变的声明。例如，您现在在列中显示一个符号，但稍后可能会更改为其他符号（甚至发出哔声）。

均匀度

您正在使用例如外观模式，而函数唯一要做的就是将函数准确地传递给另一个函数而无需更改参数。

给代码段命名时，本质上是给它命名。这可能是由于多种原因造成的，但是关键是要给它起一个有意义的名称，该名称可以添加到程序中。诸如“ addOneToCounter”之类的名称不会添加任何内容，但是conditionMet()会添加任何内容。

如果您需要一个规则来确定代码片段太短或太长，请考虑需要多长时间才能找到代码片段的有意义的名称。如果您不能在合理的时间内完成，则该代码段的大小不合适。

不，但是可能太简洁了。

切记：代码只写一次，但是读过很多遍。

不要为编译器编写代码。为将来必须维护您的代码的开发人员编写它。

是的，亲爱的，功能可能会越来越小，它的好坏取决于您使用的语言/框架。

在我看来，我主要从事前端技术方面的工作，小型函数通常用作辅助函数，当您使用小型过滤器并在整个应用程序中使用相同的逻辑时，您必然会像很多人一样使用它们。如果您的应用程序具有太多的通用逻辑，那么将会有大量的小功能。

但是，在没有通用逻辑的应用程序中，您不一定会做一些小功能，但是您可以将代码分成几个部分，以便于管理和理解。

通常，将巨大的代码分解为小函数是一种很好的方法。在现代框架和语言中，您一定会这样做，例如

data => initScroll(data)

是ES 2017 JavaScript和Typescript中的匿名函数

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

在上面的代码中，您可以看到3个函数声明和2个函数调用，这是Angular 4中带有Typescript的简单服务调用。您可以将其视为您的要求

([] 0)
([x] 1)
([x y] 2)

以上是Clojure语言中的3个匿名函数

(def hello (fn [] "Hello world"))

上一个是Clojure中的功能声明

因此，是的，FUNCTIONS可以更小，但是如果您具有以下功能，则它的好坏：

incrementNumber(numb) { return ++numb; }

好吧，这样做不是一个好习惯，但是如果您在Angular Framework中像在Angular Framework中那样在HTML标记中使用此函数，并且如果不支持Angular HTML模板中的Increment或Decrement，那将是解决方案。我。

让我们再举一个例子

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

上面的示例是在Angular HTML模板中播放数组时必须使用的示例。因此有时您必须创建一些小函数

我不同意这个时候给出的答案。

最近，我找到了一个同事，该同事编写所有的类成员，如下所示：

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

在零星的情况下，这可能是一个很好的代码，但是如果您定义了许多具有许多属性的类，那么肯定不是。我不想这样说，不得编写上述方法。但是，如果您最终将大多数代码编写为真实逻辑的“包装器”，则可能有问题。

程序员可能会错过总体逻辑，担心将来的更改以及重构代码。

接口的定义是因为有实际需要；实际上，如果您需要设置并获得一个简单的属性（没有太多逻辑，这会使成员更短），则应该可以实现。但是，如果可以用不同的方式来分析实际需求，为什么不定义一个更直观的界面呢？

要真正回答这个问题，当然不是，原因非常明显：应根据需要定义方法/属性/警告。即使是虚的虚函数也有理由存在。