“错误”的心态。
您不会因为工具抱怨这个或那个而返工类。
你想提高你的源代码的质量;这样的工具可以帮助你找到“值得思考的主题”，你把他们的反馈当作“暗示”;而不是“命令”。
因此，你不必担心类中的“代码行”，相反，你要担心的是这个类的责任。行号计数本身不是问题，但违反Single Responsibility Principle是问题。
因此：你退一步检查你的类到底在做什么，当它明显在做不止一件事时，你把这些方面提取到其他类中！
含义：如果你实际上发现所有这些代码“属于”那个类的责任;然后把它放在那里，不要把 * 内部实现细节 * 放到不相关的helper类中;仅仅因为某个工具警告你行数。
另一方面，将私有方法转换为静态/包保护的方法将允许您对这些方法进行单元测试，这可能是一个优势，但正如所述：只要我们谈的是“执行细节，”就应该保密;而且它们不应该被单元测试。
长故事代码：知道并理解什么是“干净代码”;并尝试遵循上面概述的思路。

方法的划分应该按照目的/应用/逻辑（你能想到的），而不是按照技术属性。
一个长的源代码可能会被分成几个小的类，每个类都有自己独立的用途/职责。

我经常使用包含静态方法的Utility类，发现它非常方便。如果方法真的只供单个类使用，你可以把你的Utility类作为静态私有类放在你原来的类中。但我发现在很多情况下，通用的静态Utility方法可以被几个类使用，因此在本例中，我将创建一个单独实用程序类，其中包含一组可由多个类使用的静态方法。
另外，我非常同意GhostCat的回答，从一般的思维方式来看。至于类的大小--这可能是一个问题，但通常我并不担心那么多。我真正关注的是你的方法的大小。我喜欢方法简短和自我解释，从它的名字和参数名字和顺序开始到逻辑。2如果有大块的内部逻辑--把它提取到单独的方法中。3这使得代码更好的可读性和可维护性。

代码的质量不能用行数来衡量。如果你发现类文件每天都在增长，确保你的类遵循单一责任原则。
当你的类不遵循这个原则时，把它们分成单独的类，然后把这些类做成一个包。
或者你可以把你的基类做成abstract class，把你的util方法做成abstract，有一个子类扩展基类，为基类中的抽象方法提供实现。
这是一个很好的SO answer on when you could make your methods as static
正如@扎克· Json 所说，
当你知道某些东西不会在示例间改变时，“static”通常是有价值的。2如果是这样的话，我真的会考虑“单一责任原则”，这意味着一个类应该有一个责任，因此只有一个理由改变。3我觉得应该考虑移动“ConvertMpgToKpl（double mpg）”函数和类似的方法。car对象的目的是允许示例化汽车，而不是提供它们之间的比较。这些应该是类的外部对象。
尽管static允许您在不创建对象的情况下访问方法，但在尝试将方法设置为static时，请始终记住以下几点

• 该方法根据输入参数生成一致的结果
• 您总是需要该方法位于内存中（即;你经常需要这个方法）--最好是访问一个巨大的方法，而这个方法在对象创建的帮助下只能被访问很少的次数，而不是通过static来访问它
• 经常使用的实用程序方法可以做成static

在我看来，使用私有方法做一些“魔术”是有点危险的，因为你不能真正地单元测试它。是的，当然你可以单元测试调用私有方法的公共方法，但是想想你会有渐进的复杂性。通常我更喜欢为这样的方法使用实用程序类，并编写大量的单元测试。