它有助于控制名称空间污染。

在类中将方法标记为静态可以明显地表明它不使用任何实例成员，这有助于在浏览代码时了解这一点。

你不一定要把它移到另一个类中，除非它被另一个在概念上紧密关联的类所共享。

只是我的一点钱:将所有共享的静态方法添加到实用程序类中，您就可以添加

using static className; 

到您的using语句，这使得代码更快地输入和更容易阅读。例如，我在继承的一些代码中有大量所谓的“全局变量”。我没有在一个属于实例类的类中创建全局变量，而是将它们全部设置为全局类的静态属性。它完成了这项工作，虽然有些混乱，但我可以按名称引用属性，因为我已经引用了静态名称空间。

我不知道这是不是一个好的练习。关于c# 4/5，我有很多东西要学，还有很多遗留代码要重构，所以我只是想让Roselyn的技巧来指导我。

Joey

我相信这不会发生在您的情况下，但是在我不得不忍受维护的一些代码中，我看到了使用大量静态方法的“坏味道”。

不幸的是，它们是假定特定应用程序状态的静态方法。(当然，每个应用程序只有一个用户!为什么不让User类在静态变量中跟踪它呢?)它们是访问全局变量的光荣方法。它们还有静态构造函数(!)，这几乎总是一个坏主意。(我知道有一些合理的例外)。

然而，静态方法在排除域逻辑(实际上不依赖于对象实例的状态)时非常有用。它们可以使您的代码更具可读性。

只要确保你把它们放在正确的地方。静态方法是否侵入式地操纵其他对象的内部状态?能不能证明他们的行为属于其中一类呢?如果你没有正确地分离问题，你以后可能会头疼。

对于类中的复杂逻辑，我发现私有静态方法在创建隔离逻辑时很有用，其中实例输入在方法签名中明确定义，并且不会发生实例副作用。所有输出必须通过返回值或out/ref参数。将复杂的逻辑分解成无副作用的代码块可以提高代码的可读性和开发团队对它的信心。

另一方面，它可能导致类被大量实用方法所污染。通常，逻辑命名、文档和团队编码约定的一致应用程序可以缓解这种情况。

我希望您已经理解了静态方法和实例方法之间的区别。而且，答案可以有长有短。其他人已经给出了很长的答案。

我的简短回答是:是的，你可以像ReSharper建议的那样将它们转换为静态方法。这样做没有坏处。相反，通过将方法设置为静态，实际上是在保护该方法，这样就不会不必要地将任何实例成员插入该方法。通过这种方式，您可以实现OOP原则“最小化类和成员的可访问性”。

When ReSharper is suggesting that an instance method can be converted to a static one, it is actually telling you, "Why the .. this method is sitting in this class but it is not actually using any of its states?" So, it gives you food for thought. Then, it is you who can realize the need for moving that method to a static utility class or not. According to the SOLID principles, a class should have only one core responsibility. So, you can do a better cleanup of your classes in that way. Sometimes, you do need some helper methods even in your instance class. If that is the case, you may keep them within a #region helper.