谨慎地将长函数分解为主函数和辅助函数。
我知道模块外部只会调用主函数，但它的长度可能会被证明是令人生畏的。
教科书限制了行数，但我觉得这太严格了。
P.S。我在Python编程，需要处理传入的消息。该函数返回一个包含消息的元组，但是在Python的内部数据类型中。 因此，您可以看到每种消息类型的独立代码。
重复问题
答案 0 :(得分：4)
我认为你需要从问题的另一端解决这个问题。自下而上思考。确定尽可能小的小工作单元，并开始以这种方式编写代码。当您自上而下编码并且不采用结构化方法时，您将只遇到意大利面条代码问题。
如果您已经有意大利面条代码并且需要重构，那么您几乎不得不重新开始。打破现有的意大利面条代码可能比重写它更有效，结果可能不会那么好。
我认为方法中的代码行不应该有一个硬编号，但编写良好的代码在较低层中没有超过5到10行的方法，而在20到30行中没有业务逻辑。给你一些指标。
答案 1 :(得分：3)
一个好的经验法则是，如果它不适合单个屏幕，则值得思考将其拆分。但只有将它分开才有意义，一些长函数才是完全可读的，只是为了它而将它们盲目地分割成多个函数没有任何意义。
答案 2 :(得分：3)
我不是不必要地将功能分解为多个功能的忠实粉丝。这不是一件很难和快速的事情 - 如果有些东西看起来像是不同的逻辑单元，那么无论如何都要打破它们并分别考虑它们。但是，不要为了某些指导方针而解决问题，例如“每个功能一页”或“每个功能N行”。
答案 3 :(得分：2)
永远不要写一个在折叠纸上打印时比你高的功能。
答案 4 :(得分：2)
我喜欢经验法则，如果你能想到一个好的域相关名称，你应该打破子功能。
当有人能够理解顶级功能而无需查询子功能的定义时，您可能会获得净收益。 （但是当你把它分解得太远时，你的名字就会开始引用你的实现工件，而不是域名）
答案 5 :(得分：1)
我最近和一位朋友讨论过这件事。他建议重构以解决问题，我必须说我必须同意。也就是说，一个函数应该做一件事，如果它做了不止一件事，就把它分开。如果没有，让它在一起，分开一个函数是没有意义的，只是让它混淆了意义。毕竟，函数是一个代码块，它做了一件事！
答案 6 :(得分：1)
线条数量的限制通常是不切实际的，因为它不能很好地解释可读性。最好尝试分离只有少量输入和几个输出的代码行，并将其作为一个单独的功能。这并不总是可行的 - 然后通常明智地保留代码，而不是为了重构而重构代码。
答案 7 :(得分：1)
好吧，因为我在Python编码所以我可以自由地在函数内部编写函数，这与C，C ++或Java不同。我认为这是一个更好的选择。
答案 8 :(得分：1)
它没有指定。但线应尽可能低。但是您可以遵循 30 的角色。需要时，我会在 PHP 脚本中遵循这一点。
30 法则：
Martin Lippert 和 Stephen Roock 在大型软件项目中重构的“30 法则”：
方法的平均代码行不应超过 30 行。
一个类平均应该包含少于 30 个方法。
一个包/库不应包含超过 30 个类。
子系统应该避免超过 30 个包。
超过 30 个子系统的系统可能会产生问题。
如果一个元素由超过 30 个子元素组成，很可能存在严重问题。
答案 9 :(得分：0)
个人如果要么节省总行数或总处理时间，我会破坏一个功能。
如果我每个主要功能只运行一次助手我不打扰
答案 10 :(得分：0)
关键是原则上最好有专门的功能。但是，设置限制的地方在很大程度上取决于 1）某些语言中的“通常”编程风格。 （可以观察到，面向对象的语言倾向于缩短程序，而不是说C等 2）这取决于你的编程方式。每个硬限制都必须受到质疑。恕我直言。总体而言，可能会有一些“自然”的节目分发 3）我认为一个人应该记住的是一个函数应该做一个特定的任务，例如解析它的一些函数通常比一个函数只需要在一个结构中设置一些字段。或者回过头来考虑Windows API中的事件循环可能看起来如何。所有这些都表明长期方法可能有充分的理由......
答案 11 :(得分：0)
如果有独立代码（在每种情况下针对每种消息类型），那么应该打破这些区域。
答案 12 :(得分：0)
尺寸不重要。按我的身材判断你呢？ - 尤达
您主要关心的是可读性，简单性和可维护性。一个好的指标是，如果你需要编写注释来解释一个函数的一部分，那么该部分是一个单独函数的一个很好的候选者。
答案 13 :(得分：0)
如果你没有写它并且它已经投入生产：永远不要！如果你打破它，你可能会打破它，就这么简单。
如果你正在编写并且你不确定，屏幕上的规则就像其他人所说的一样。
答案 14 :(得分：0)
将很多功能分解为其组成部分的原因有很多。最重要的是：
一些简单的功能不能在不对所列目标产生负面影响的情况下分解成更小的部分，因此没有严格的规则。