我经常发现自己创建了保存小（＆lt; 50行）算法的方法。但是，当我第一次学习方法时，我们不断被教导它们是一种通过在块中包含常用代码片段来压缩/清理代码的方法。
我喜欢使用方法，不仅仅是为了这个目的，而是为了容纳小片段，以便我的主要方法干净且易于理解，并且代码的“肉”隐藏在这些方法中。在风格上，这是不正确的吗？
答案 0 :(得分：7)
将大型方法分解为较小的方法以提高可读性是没有错的。
它有几个好处，特别是如果你将每个方法保持在一个抽象级别 - 使大方法流畅地阅读并使每个小方法简单易懂。
答案 1 :(得分：0)
不，这不是不正确的。编写代码时应该有多个目标。通过将代码合并到可重用的类和方法中而不重复代码，可以说明可维护性。将工作项目分解为特殊方法可以提高可读性，这也有助于提高可维护性。
像所有事情一样，寻求平衡。必须精神上遍历过多级别的调用堆栈以理解算法或找到缺陷可能会成为一个缺点。但是如果一个方法大约有50行，我发现很难相信你会遇到这种情况。
答案 2 :(得分：0)
从风格上讲，至少从我的经验来看，这并不是错误的。我之所以这么说是因为一个程序，如果由一个或一百个程序员编写，将由程序员/程序员的才能和经验组成和完成。这意味着有很多方法可以解决问题，你应该问自己的问题是我的实施工作吗？它完成了任务/功能吗？如果是这样，那就太好了！
因为你关注风格，我会把你推荐给Uncle Bob's SOLID principles，正如许多其他人在风格上提出的类似问题一样。你提到在一个方法中有一个由＆lt; 50行代码组成的算法，我认为尽可能地尽可能地遵循Bob叔叔的单一责任（S.O.L.I.D中的'S'）原则。这将挑战你看看那个＆lt; 50 line-in-a-single-method算法，并考虑把它分解成更多专注于做一件事的方法，一件好事。这样您就可以实现可测试性和可读性。这些总是两件事情将会走向“好风格”。