Method can be made static, but should it?

Question

Resharper likes to point out multiple functions per asp.net page that could be made static. Does it help me if I do make them static? Should I make them static and move them

Answer 1

Static methods versus Instance methods
10.2.5 Static and instance members of the C# Language Specification explains the difference. Generally, static methods can provide a very small performance enhancement over instance methods, but only in somewhat extreme situations (see this answer for some more details on that).

Rule CA1822 in FxCop or Code Analysis states:

"After [marking members as static], the compiler will emit non-virtual call sites to these members which will prevent a check at runtime for each call that ensures the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue."

Utility Class
You shouldn't move them to a utility class unless it makes sense in your design. If the static method relates to a particular type, like a ToRadians(double degrees) method relates to a class representing angles, it makes sense for that method to exist as a static member of that type (note, this is a convoluted example for the purposes of demonstration).

Answer 2

I hope, you have already understood the difference between static and instance methods. Also, there can be a long answer and a short answer. Long answers are already provided by others.

My short answer: Yes, you can convert them to static methods if Resharper suggests. There is no harm in doing so. Rather, by making the method static, you are actually guarding the method so that, unnecessarily you do not slip any instance members to that method. In that way, you can achieve an OOP principle "Minimize the accessibility of classes and members".

When ReSharper is suggesting that an instance method can be converted to a static method, it is actually telling you, "Why the .. this method is sitting in this class as 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.

Answer 3

This is interesting read:

http://thecuttingledge.com/?p=57

ReSharper isn’t actually suggesting you make your method static. You should ask yourself why that method is in that class as opposed to, say, one of the classes that shows up in its signature...

but here is what resharper documentaion says: http://confluence.jetbrains.net/display/ReSharper/Member+can+be+made+static

Answer 4

ReSharper does not check the logic. It only checks whether the method uses instance members. If the method is private and only called by (maybe just one) instance methods this is a sign to let it an instance method.

Answer 5

Marking a method as static within a class makes it obvious that it doesn't use any instance members, which can be helpful to know when skimming through the code.

You don't necessarily have to move it to another class unless it's meant to be shared by another class that's just as closely associated, concept-wise.

Answer 6

I'm sure this isn't happening in your case, but one "bad smell" I've seen in some code I've had to suffer through maintaining used a heck of a lot of static methods.

Unfortunately, they were static methods that assumed a particular application state. (why sure, we'll only have one user per application! Why not have the User class keep track of that in static variables?) They were glorified ways of accessing global variables. They also had static constructors (!), which are almost always a bad idea. (I know there are a couple of reasonable exceptions).

However, static methods are quite useful when they factor out domain-logic that doesn't actually depend on the state of an instance of the object. They can make your code a lot more readable.

Just be sure you're putting them in the right place. Are the static methods intrusively manipulating the internal state of other objects? Can a good case be made that their behavior belongs to one of those classes instead? If you're not separating concerns properly, you may be in for headaches later.