测量关中断时间的功能_功能应该多久才能测量

测量关中断时间的功能

功能是否有最大行数？ (Is there a max number of lines for functions?)

We are all very familiar with how functions help us write better code. They provide two main benefits, reusability and abstraction. This creates code that is DRY and easy to follow.

我们都非常熟悉函数如何帮助我们编写更好的代码。 它们提供了两个主要好处，即可重用性和抽象性。 这将创建简单且易于执行的代码。

Now you might also be familiar with the idea that your functions should be small. The smaller the better! When doing my Bootcamp I had an instructor mention that if a function was more than 5–10 lines you should consider making another function. I did not stick to this rule. So I decided to research this and see how relevant this was.

现在，您可能还熟悉函数应该很小的想法。 越小越好！ 在进行我的Bootcamp时，我有一位讲师提到如果一个功能超过5–10行，则应考虑制作另一个功能。 我没有遵守这个规则。 因此，我决定对此进行研究，以了解其相关性。

Side note: I am using the term “function” generally here. They are functions in JavaScript and they would be methods in Ruby and subroutines in Java etc…

旁注：我在这里通常使用术语“功能”。 它们是JavaScript中的函数，它们将是Ruby中的方法和Java中的子例程等。

度量：行数 (Measure: number of lines)

I spent some time researching the number of lines a function should be and wow the answers were varied! Some will say more than 5 lines need a refactor, some will say 5–15 lines, some say 30 and some say below 100 is all good. Now that’s quite the range! And with little to no explanation on why a certain number of lines means anything at all. For the most part, it seems people did agree that number of lines is not a good indicator for length.

我花了一些时间研究一个函数应该的行数，哇，答案是多种多样的！ 有些人会说超过5条线需要重构，有些人会说5-15条线，有些人说30条线，有些人说低于100条线都是好的。 现在就可以了！ 几乎没有解释为什么一定数量的行根本没有任何意义。 在大多数情况下，似乎人们确实同意行数不是长度的良好指标。

Now even though you can’t use an exact number of lines of code to determine if your method is too long, if you see that your function is over 200–300 lines it’s probably worth a second look. It can help you identify especially lengthy functions that may benefit from a refactor.

现在，即使您无法使用确切的代码行数来确定您的方法是否过长，但如果您发现函数超过200–300行，则可能值得再次看一下。 它可以帮助您确定可能需要重构的冗长功能。

Since the number of lines is not a good indicator of how long your functions should be, here are some other measures that may be helpful:

由于行数不能很好地指示您的功能应该持续多长时间，因此以下一些其他措施可能会有所帮助：

度量：屏幕尺寸 (Measure: the size of your screen)

One measure I came across in my research is the size of your screen. Essentially, if your function is larger than what fits on your screen at one time then your function is too long. There should be no scrolling required.

我在研究中遇到的一项指标是屏幕的尺寸。 本质上，如果您的功能一次大于屏幕上显示的内容，那么您的功能就太长了。 不需要滚动。

There are some benefits to keeping your functions at this length:

将函数保持在此长度有一些好处：

• It is easier to see the algorithm as a whole when you can see it all together. The flow of the logic is easier to see and easier to hold in your head.
  当您可以一起查看算法时，更容易将其作为一个整体来看。 逻辑流程更容易看到，也更容易掌握。
• It makes it easier to spot a bug or find a specific block in the code. Finding this block of code would be much harder if you had to sift through many lines of code and scroll as you look.
  它使发现错误或在代码中查找特定块变得更加容易。 如果您不得不筛选许多行代码并按自己的方式滚动，那么查找此代码块将更加困难。

衡量：他们做的事情数量 (Measure: the number of things they do)

A function can also be measured by the number of things it achieves. This is an excellent measure of a function since functions should do one thing. This helps keep your functions from becoming too complex. Some benefits of functions having a singular purpose are:

函数也可以通过实现的数量来衡量。 这是对功能的极好衡量，因为功能应该做一件事。 这有助于防止您的功能变得过于复杂。 具有单一目的的功能的一些好处是：

• If they do one thing, they can focus on doing the thing well. Refactoring can be more efficient.
  如果他们做一件事情，他们可以专注于做好事情。 重构可以更有效。
• It helps make your code self explanatory. With descriptive naming, it is clear what each function does and fewer comments are needed.
  它有助于使您的代码易于说明。 使用描述性命名，可以很清楚地看到每个函数的功能，并且需要更少的注释。
• It is possible to perform more accurate unit testing
  可以执行更准确的单元测试

措施：完成工作 (Measure: getting the job done)

Now you can try to follow all the measures above and see that that in some cases they just simply don’t work. And guess what? that’s ok! At the end of the day, the only measure that will matter is if your functions do the tasks they are supposed to.

现在，您可以尝试遵循上述所有措施，并发现在某些情况下它们只是行不通。 你猜怎么着？ 没关系！ 归根结底，唯一重要的衡量标准是您的功能是否执行了应该执行的任务。

One major exception to the small function idea is switch cases. Sometimes it’s justifiable to have a large switch statement with many cases that end up being lines and lines of code. However, if the logic is sound, there is no need to make this function smaller.

小功能构想的一个主要例外是开关盒。 有时，有一个很大的switch语句是有道理的，许多情况下最终都是几行代码。 但是，如果逻辑是合理的，则无需缩小此功能。

简而言之， (In short,)

Question: How long should your functions be?

问题：您的功能应该持续多长时间？

Answer: As long as it needs to be but also as short as possible.

答：只要需要，但也要尽可能短。

翻译自: https://medium.com/swlh/how-long-should-functions-be-how-do-we-measure-it-cccbdcd8374c

测量关中断时间的功能