blocks|key|2019116|text|我总是把长方法分解成逻辑块，然后试着把它们变成更小的方法。我通常不会将几行代码转换成一个单独的方法，直到我在两个不同的地方需要它，但有时我这样做只是为了提高可读性，或者如果我想单独测试它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2019117|Fowler的Refactoring就是关于这个主题的，我强烈推荐它。|offset|length|2019118|下面是我在重构中使用的一条方便的经验法则。如果有一段代码有注释，我可以将其重新添加到方法名中，将其拉出并使其成为方法。|2019119|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0201485672^0|0|7|B|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

I always break long methods up into logical chunks and try to make smaller methods out of them. I don't normally turn a few lines into a separate method until I need it in two different places, but sometimes I do just to help readability, or if I want to test it in isolation.

Fowler's <a href="https://rads.stackoverflow.com/amzn/click/com/0201485672" rel="noreferrer" rel="nofollow noreferrer">Refactoring</a> is all about this topic, and I highly recommend it.

Here's a handy rule of thumb that I use from Refactoring. If a section of code has a comment that I could re-word into a method name, pull it out and make it a method.

blocks|key|2793946|text|和往常一样，你可以说:视情况而定。这更多的是一个命名和定义方法任务的问题。每个方法应该完成一个(而不是更多)定义良好的任务，并且应该完整地完成它们。方法的名称应指示任务。如果您的方法名为DoAandB()，那么使用单独的方法DoA()和DoB()可能会更好。如果您需要像setupTask、executeTask、FinishTask这样的方法，那么将它们组合起来可能会很有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2793947|一些要点表明，不同方法的合并可能是有用的：|2793948|2793949|如果不使用其他方法，则不能单独使用方法。|unordered-list-item|2793950|您必须注意以正确的顺序调用某些依赖方法。|2793951|2793952|一些要点表明，拆分该方法可能很有用：|2793953|2793954|现有方法中的一些行有明显的独立task.|2793955|Unit-testing的大方法出问题。如果为独立的方法编写测试更容易，那么拆分大的方法。|2793956|2793957|作为对单元测试参数的解释:我写了一个方法，它做了一些事情，包括IO。IO部分很难测试，所以我考虑了一下。我得出的结论是，我的方法做了5个逻辑独立的步骤，其中只有一个涉及IO。所以我将我的方法分成5个较小的方法，其中四个很容易测试。|2793958|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|15|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|17|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|V|$]]

As always you can say: it depends. It's more a question of naming and defining the task of a method. Every method should do one (not more) well defined task and should do them completely. The name of the method should indicate the task. If your method is named DoAandB() it may be better to have separate methods DoA() and DoB(). If you need methods like setupTask, executeTask, FinishTask, it may be useful to combine them.

Some points that indicate, that a merge of different methods may be useful:

<ul>
<li>A method cannot be used alone, without the use of other methods.</li>
<li>You have to be careful to call some dependent methods in the right order.</li>
</ul>

Some points that indicate, that a splitup of the method could be useful:

<ul>
<li>Some lines of the existing method have clear independent task.</li>
<li>Unit-testing of the big method gets problematic. If tests are easier to write for independent methods, then split the big method up.</li>
</ul>

As an explanation to the unit-test-argument: I wrote a method, that did some things including IO. The IO-part was very hard to test, so I thought about it. I came to the conclusion, that my method did 5 logical and independent steps, and only one of them involved the IO. So I split up my method into 5 smaller ones, four of them were easy to test.

blocks|key|105596|text|一些经验法则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|105597|105598|函数不应比屏幕上显示的函数长，如果|unordered-list-item|105599|函数使代码更具可读性，则将函数拆分为较小的函数。|105600|105601|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

Some rules of thumb:

<ul>
<li>Functions should not be longer than what can be displayed on screen</li>
<li>Break functions into smaller ones if it makes the code more readable. </li>
</ul>

blocks|key|2794001|text|就我个人而言，我明显倾向于偏爱更多、更小的方法，但不会盲目地追求最大行数。我的主要标准或目标是保持代码干燥。一旦我有了一个复制的代码块(无论是在精神上还是实际上是由文本复制的)，即使它可能有2到4行长，我也会将该代码干掉到一个单独的方法中。有时，如果我认为它有很好的机会在未来再次使用，我会提前这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2794002|另一方面，我也听到有人争论说，如果你的中断方法太小，在一个开发团队的上下文中，一个队友很可能不知道你的方法，并且会写内联，或者写他自己的小方法来做同样的事情。无可否认，这是一个糟糕的情况。|2794003|一些人还试图争辩说，保持内容内联更具可读性，这样读者就可以自上而下地阅读，而不必跳过方法定义，可能会跨越多个文件。就我个人而言，我认为堆栈跟踪的存在使得这不是一个大问题。|2794004|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Personally, I lean significantly in the direction of preferring more, smaller methods, but not to the point of religiously aiming for a maximum line count. My primary criterion or goal is to keep my code DRY. The minute I have a code block which is duplicated (whether in spirit or actually by the text), even if it might be 2 or 4 lines long, I DRY up that code into a separate method. Sometimes I will do so in advance if I think there's a good chance it will be used again in the future.

On the flip side, I have also heard it argued that if your break-off method is too small, in the context of a team of developers, a teammate is likely not to know about your method, and will either write inline, or write his own small method that does the same thing. This is admittedly a bad situation.

Some also try to argue that it is more readable to keep things inline, so a reader can just read top-down, instead of having to jump around method definitions, possibly across multiple files. Personally, I think the existence of a stack trace makes this not much of an issue.

blocks|key|4906991|text|方法越大，测试和维护就越困难。我发现，当一个大型流程分解为原子步骤时，它更容易理解它是如何工作的。此外，这样做是使您的类可扩展的第一步。您可以将这些单独的步骤标记为虚拟的(用于继承)，或者将它们移动到其他对象(组合)中，从而使您的应用程序的行为更易于定制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4906992|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The bigger the method, the harder to test and maintain. I find its much easier to understand how a large process works when its broken down into atomic steps. Also, doing this is a great first step to make your classes extensible. You can mark those individual steps as virtual (for inheritance), or move them into other objects (composition), making your application's behavior easier to customize.

blocks|key|4907004|text|该方法的大小直接链接到它的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4907005|保持方法大小较小(这意味着将一个大方法划分为几个小方法)的主要优点是：|4907006|4907007|更好的单元测试(由于更显式的堆栈跟踪(而不是一个巨大方法中的一个错误)导致的低圈complexity)|unordered-list-item|4907008|better调试)|4907009|4907010|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

The size of the method is directly linked to its <a href="https://stackoverflow.com/questions/105852">cyclomatic complexity</a>.

The main advantages to keep the size of the method small (which means dividing a big method into several small methods) are:

<ul>
<li>better unit testing (due to low cyclomatic complexity)</li>
<li>better debugging due to a more explicit stack trace (instead of one error within one giant method)</li>
</ul>

blocks|key|105660|text|我发现有许多小方法可以使代码更容易阅读、维护和调试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|105661|当我通读实现了一些业务逻辑的单元时，如果我看到一系列描述流程的方法调用，我可以更好地遵循流程。如果我关心方法是如何实现的，我可以查看代码。|105662|这感觉像是更多的工作，但它最终节省了时间。|105663|我认为，知道要封装什么是一门艺术。每个人都有一些细微的不同意见。如果我可以用语言表达，我会说每个方法都应该做一件可以被描述为完成任务的事情。|105664|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I find that having many small methods makes code easier to read, maintain and debug. 

When I'm reading through a unit that implements some business logic, I can better follow the flow if I see a series of method calls that describe the process. If I care about how the method is implemented, I can go look in the code.

It feels like more work but it ultimately saves time.

There is an art, I think, to knowing what to encapsulate. Everyone has some slight difference of opinion. If I could put it in words I'd say that each method should do one thing that can be described as a complete task.

blocks|key|2794138|text|我通常倾向于将函数拆分成更小的函数，每个函数执行一个单独的原子任务，但只有当该函数足够复杂才能保证它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2794139|这样，我就不会为简单的任务使用多个函数，而且我提取的函数通常可以在其他地方使用，因为它们不会尝试实现太多。这也有助于单元测试，因为每个功能(作为逻辑的原子操作)都可以单独测试。|2794140|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I usually go for splitting functions into smaller functions that each perform a single, atomic task, but only if that function is complex enough to warrent it.

This way, I don't end up with multiple functions for simple tasks, and the functions I do extract can typically be used elsewhere as they don't try to achieve too much. This also aids unit testing as each function (as a logical, atomic action) can then be tested individually.

blocks|key|4907145|text|每次都是小方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4907146|它们是自我记录的(如果命名得当的话)|4907147|他们将问题分解成可管理的部分--你是KeepingItSimple。|4907148|您可以使用OO技术来更容易(也更明显)地插入行为。根据定义，大型方法更具过程性，因此灵活性较差。|4907149|它们是单元可测试的。这是杀手级的，你根本不能对执行大量任务的大型方法进行单元测试|4907150|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Small methods every time.

They are self documenting (er, if well named)

They break down the problem into manageable parts - you are KeepingItSimple.

You can use OO techniques to more easily (and obviously) plug in behaviour. The large method is by definition more procedural and so less flexible.

They are unit testable. This is the killer, you simply can’t unit test some huge method that performs a load of tasks

blocks|key|105733|text|我从Code+Complete一书中学到的一些东西：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|105734|105735|编写方法/函数，以便实现一个逻辑块(或单元或任务)。如果这需要分解为子任务，则为它们编写一个单独的方法/函数并调用它们。|unordered-list-item|105736|如果我发现方法/函数名越来越长，那么我会尝试检查该方法，看看它是否可以分解为两个方法。|105737|105738|希望这能有所帮助|105739|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

Something I learnt from The Code Complete book:

<ul>
<li>Write methods/functions so that it
implement one chunk(or unit or task)
of logic. If that requires breakdown
into sub tasks, then write a
seperate method/function for them
and call them.</li>
<li>If I find that the method/function
name is getting long then I try to
examine the method to see it it can
be broken down into two methods.</li>
</ul>

Hope this helps

blocks|key|107688|text|这要看情况..。在心态上。不过，这并不是一个固执己见的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|107689|答案实际上取决于语言环境。|107690|在Java/C#/C%2B%2B的世界里，人们遵循Robert+Martin所宣扬的"Clean+Code“学派，那么:许多小方法是可行的。|107691|一个方法有一个清晰的名字，并且只做一件事。一层嵌套，仅此而已。这将其长度限制为3，5，最多10行。|107692|老实说:我发现这种编码方式绝对优于任何其他“风格”。|107693|这种方法的唯一缺点是最终会有许多小方法，因此文件/类中的排序可能会成为一个问题。但是，解决这个问题的方法是使用一个像样的IDE，它可以方便地来回导航。|107694|因此，使用“所有东西都放在一个方法/函数中”的唯一“合法”理由是，当你的整个团队都像这样工作，并且更喜欢这种风格时。或者当你不能使用像样的工具时(但是导航那个又大又难看的函数也不能工作)。|107695|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

It depends a bit ... on mindset. Still, this is not an opinionated question.

The answer rather actually depends on the language context.

In a Java/C#/C++ world, where people are following the "Clean Code" school, as preached by Robert Martin, then: many small methods are the way to go.

A method has a clear name, and does one thing. One level of nesting, that's it. That limits its length to 3, 5, max 10 lines.

And honestly: I find this way of coding absolutely superior to any other "style". 

The only downside of this approach is that you end up with many small methods, so ordering within a file/class can become an issue. But the answer to that is to use a decent IDE that allows to easily navigate forth and back. 

So, the only "legit" reason to use the "all stuff goes into one method/function" is when your whole team works like that, and prefers that style. Or when you can't use decent tooling (but then navigating that big ugly function won't work either).

Is it better to write many small methods (or functions), or to simply write the logic/code of those small processes right into the place where you would have called the small method? What about breaking off code into a small function even if for the time being it is only called from one spot?

If one's choice depends on some criteria, what are they; how should a programmer make a good judgement call?

I'm hoping the answer can be applied generally across many languages, but if necessary, answers given can be specific to a language or languages. In particular, I'm thinking of SQL (functions, rules and stored procedures), Perl, PHP, Javascript and Ruby.

Best practices: Many small functions/methods, or bigger functions with logical process components inline?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

是编写许多小方法(或函数)更好，还是简单地将这些小过程的逻辑/代码直接写到调用小方法的地方？将代码分解成一个小函数，即使暂时只从一个地方调用它，又会怎样呢？如果一个人的选择依赖于一些标准，那么这些标准是什么?程序员应该如何做出好的判断？我希望答案可以普遍适用于多种语言，但如果有必要，给出的答案可以特定于一种或几种语言。...

问最佳实践:许多小函数/方法，还是具有内联逻辑流程组件的大函数？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问最佳实践:许多小函数/方法，还是具有内联逻辑流程组件的大函数？EN