最佳实践:许多小函数/方法,或具有内联逻辑过程组件的更大函数？

编写许多小方法(或函数),或者将这些小进程的逻辑/代码直接写入您调用小方法的地方是否更好？那么将代码分解成一个小函数呢,即使暂时只从一个地方调用它？

如果一个人的选择取决于某些标准,他们是什么; 程序员应如何做出好的判断？

我希望答案可以普遍应用于多种语言,但如果有必要,给出的答案可以特定于一种或多种语言.特别是,我正在考虑SQL(函数,规则和存储过程),Perl,PHP,Javascript和Ruby.

我总是把很长的方法分解成逻辑块,并尝试用它们制作更小的方法.我不正常转了几行到一个单独的方法,直到我需要它在两个不同的地方,但有时候我只是为了帮助可读性,或者如果我想测试它孤立.

Fowler的Refactoring就是这个话题,我强烈推荐它.

这是我从重构中使用的一个方便的经验法则.如果一段代码中有一条注释,我可以将其重新命名为方法名称,请将其拉​​出并使其成为方法.

该方法的大小与其圈复杂度直接相关.

保持方法尺寸小的主要优点(这意味着将一个大方法分成几个小方法)是:

更好的单元测试(由于低的圈复杂度)

由于更明确的堆栈跟踪(而不是一个巨型方法中的一个错误),可以更好地进行调试

一如既往,你可以说:这取决于.这更像是命名和定义方法任务的问题.每个方法都应该做一个(不是更多)明确定义的任务,并且应该完全完成它们.方法的名称应指明任务.如果您的方法名为DoAandB(),则最好使用单独的方法DoA()和DoB().如果您需要setupTask,executeTask,FinishTask等方法,则将它们组合起来可能很有用.

有些观点表明,不同方法的合并可能有用:

不使用其他方法,不能单独使用方法.

您必须小心按正确的顺序调用某些依赖方法.

有些观点表明,方法的拆分可能很有用:

现有方法的某些行具有明确的独立任务.

大方法的单元测试会产生问题.如果为独立方法编写测试更容易,那么将大方法拆分.

作为单元测试参数的解释:我写了一个方法,它做了一些包括IO在内的事情.IO部分很难测试,所以我想到了.我得出结论,我的方法做了5个逻辑和独立的步骤,其中只有一个涉及IO.所以我将我的方法分成5个较小的方法,其中4个很容易测试.

每次都是小方法.

它们是自我记录的(呃,如果命名得当)

他们将问题分解为可管理的部分 - 你是KeepingItSimple.

您可以使用OO技术更容易(并且显然)插入行为.根据定义,大方法更具程序性,因此不太灵活.

它们是可单元测试的.这是杀手,你根本无法对一些执行大量任务的巨大方法进行单元测试