良好的编码惯例:何时创建新功能

时间:2013-06-27 17:00:22

标签: function language-agnostic code-readability

我有一个使用相同的功能(少数,2-5,具体取决于我如何更改它以适应将来可能使用的)代码行4次。

我看了this question,但这对我来说不够具体,与我的目标不符。

这里有一些

function myFunction() {
  if (something) {
    // Code line 1
    // Code line 2
    // Code line 3
  }
  else if (somethingElse) {
    // Code line 1
    // Code line 2
    // Code line 3
  }
  else if (anotherThing) {
    // Code line 1
    // Code line 2
    // Code line 3
  }
  else if (theLastThing) {
    // Code line 1
    // Code line 2
    // Code line 3
  }
  else {
  // Not previously used code
  }
}

复制/粘贴相同的3行代码(如果满足任何这些条件,则构造相同的对象)。创建一个我可以传递所有这些信息并在完成后返回必要信息的函数是一个好习惯吗?所有这些条件语句都在 可以运行1000次左右的循环中。

我不确定通过跳转到另一个函数来准备堆栈帧(?)的成本是否超过1000次迭代的成本更高,值得拥有~15行重复代码。显然,功能化使它更具可读性,但这是非常具体的功能,其他地方。我可以编写以消除复制/粘贴心态的功能类似于:

function myHelperFunction(someParameter, someOtherParameter) {
  // Code line 1
  // Code line 2
  // Code line 3
  return usefulInformation;
}

然后将所有条件语句中的函数调用为每个条件语句1行:

myHelperFunction(myPassedParameter, myOtherPassedParameter);

基本上将这12行变为4。

所以问题 - 一般来说这是一个很好的做法,为少量代码创建一个新函数以节省一些空间和可读性?或者跳跃功能的成本是否太值得值得?是否始终为将来可能复制/粘贴的任何代码创建新功能?

PS - 据我所知,如果要在不同的(类)或源文件中使用这些代码,那么将其转换为函数是合乎逻辑的,以避免需要找到复制/粘贴的所有位置为了做出改变。但我或多或少地谈论单文件/单类或功能这种两难的问题。 此外,如果我没有正确地做到这一点,请随时修复我的标签/标题。我不太确定如何正确标题/标记这篇文章。

5 个答案:

答案 0 :(得分:3)

任何不是算法/数据结构问题的优化问题的答案是:描述您的代码!只优化显示为问题区域的内容。

这意味着您应该了解函数调用开销是否实际上是您正在编写的特定程序中的性能问题。如果是,则内联代码。如果不是,请不要。就这么简单。

答案 1 :(得分:1)

是创建一个函数,通常你应该遵循DRY主体。不要重复自己。

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

对于类似这样的事情,你的堆栈操作将是最小的。请参阅Imre Kerr对您问题的评论。

这不仅仅是为了可读性。原因很多。可维护性是巨大的。如果这个代码必须改变,那么对于其他人来说,试图找出每个地方来改变它将是一件痛苦的事情。只需在一个地方更改代码就好了。

答案 2 :(得分:1)

在我看来,你是以错误的方式接近这个。首先,您不应该使用多个(else)ifs,它们都执行相同的代码;使用一个复合或预先计算(在这种情况下,我建议由于所有可能的子条件预先计算)条件。这样的事情可能会使维护代码变得更加容易。

function myFunction() {
  bool condition = something ||
                   somethingElse ||
                   anotherThing ||
                   theLastThing;

  if (condition) {
    // Code line 1
    // Code line 2
    // Code line 3
  }
  else {
  // Not previously used code
  }
}

答案 3 :(得分:1)

我不知道这是否适用于您提供的示例,但分解代码不是编写函数的唯一原因,您也可以考虑测试

一个功能提供了一个可以单独测试的编程单元。

因此,可能会将复杂操作分解为几个更简单/更基本的单元,即使这些函数只调用一次。

由于您提出了几行代码的问题,您可以问自己:

  • 我可以合理地命名这个功能吗?
    (只是这个应该没问题,不要这么做,然后再少一点)
  • 是否有合理数量的参数?
    (我想说两三个)
  • 是否值得将其作为一个单独的单元进行测试?(它是否简化了整体测试)
  • 是这样的函数调用更易读/可理解的代码吗?
    (如果前两个问题的答案是否定的,则不一定明显)

答案 4 :(得分:0)

这是一个很好的问题,答案是:这取决于。

就个人而言,我会创建一个提高代码可读性的功能,但如果您正在寻找效率,可能需要复制和粘贴代码。

相关问题