35线、55线、100线、300线？你什么时候应该开始把它分开？我这么问是因为我有一个有 60 行（包括注释）的函数，并且正在考虑将其拆分。
long_function(){ ... }
into:
small_function_1(){...}
small_function_2(){...}
small_function_3(){...}
这些函数不会在 long_function 之外使用，使函数更小意味着更多的函数调用，等等。
什么时候你会把一个函数分解成更小的函数？为什么？
- 方法应该只做一件合乎逻辑的事情（考虑功能）
- 您应该能够用一句话解释该方法
- 它应该适合您显示器的高度
- 避免不必要的开销（指出明显问题的评论......）
- 对于小型逻辑功能来说单元测试更容易
- 检查部分函数是否可以被其他类或方法重用
- 避免过度的类间耦合
- 避免深层嵌套的控制结构
谢谢大家的回答，编辑列表并投票选出正确答案，我会选择那个；）
我现在正在重构这些想法:)
以下是可能表明函数太长的危险信号列表（排名不分先后）：
深度嵌套的控制结构: 例如for 循环深度为 3 层，甚至只有 2 层，并且具有复杂条件的嵌套 if 语句。
太多国家定义参数: By 状态定义参数，我的意思是一个函数参数，它保证函数的特定执行路径。如果获取太多此类参数，则会出现执行路径的组合爆炸（这通常与#1 同时发生）。
其他方法中重复的逻辑：糟糕的代码重用是造成单一程序代码的一个巨大因素。很多这样的逻辑重复可能非常微妙，但一旦重新考虑，最终结果可能是更加优雅的设计。
类间耦合过度：缺乏适当的封装会导致函数与其他类的密切特征相关，从而延长它们。
不必要的开销：指出明显的深层嵌套类、私有嵌套类变量的多余 getter 和 setter 以及异常长的函数/变量名称的注释都可能在相关函数中产生语法噪音，最终会增加其长度。
您的大型开发人员级显示器不够大，无法显示它：实际上，当今的显示器已经足够大，任何接近其高度的功能都可能太长。但是，如果是的话larger，这是确实有问题的证据。
您无法立即确定该函数的用途: 另外，一旦你真的do确定它的目的，如果你不能用一句话概括这个目的或者碰巧非常头疼，这应该是一个线索。
总之，单体函数可能会产生深远的影响，并且通常是重大设计缺陷的症状。每当我遇到绝对的代码时joy读起来，它的优雅立刻显而易见。你猜怎么着：这些功能通常是very长度短。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
