Jul 212011

ReSharper is virtually the same thing as Visual Studio for me.  I’ve used the two together for so long that it’s very difficult to imagine the Visual Studio IDE without the ReSharper feature set.

One of the things that ReSharper will do is highlight for you when a method can be made static (or Shared in VB).  I’ve run across enough people who have wondered about the benefits or disadvantages of making methods static that I thought I’d help you out a bit: ReSharper isn’t actually suggesting you make your method static.

Oh, I know it looks that way, mostly because the ReSharper message is, “Method X can be made static,” but what ReSharper actually means is, “Are you sure you have Method X in the right place?”

The primary way ReSharper knows if a method can be made static is if your method uses no instance members of the class it’s inside, and if that’s the case, 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.  Seven times out of ten, you’ll find that your method is much more at home (and more closely adhering to the Single Responsibility Principle) if it resides as a non-static method of another class, and the classes in the signature of the method or the classes in the calls to the method are a great place to start, because then you’d be using actual instance members.

For instance, if I have code, let’s say in a viewmodel or presenter or some kind of “getting the screen stuff ready” class, that looks like this:

private string FormatName(string firstName, string lastName)


return string.Format(“{0}, {1}”, lastName, firstName);


And I call it like this:

FullName = FormatName(customer.FirstName, customer.LastName);

And ReSharper suggests the method could be made static, it’s appropriate to consider whether or not I’m doing this right.  Perhaps FullName should be a property of my customer object, formatted the way I want.

If FormatName is of more general use than that, I might consider making it an extension method.  It’s a judgment call, certainly, but I’ve seen a lot of applications with static formatting methods that could have easily been made extension methods and rightly so.

It’s also possible that the method should go in a class full of static methods.  Utility functions are famous (or infamous) for ending up this way.  You want to be careful, because these utility classes often end up becoming dumping grounds for unrelated methods that don’t seem to go anywhere else, and they become more like miscellaneous classes than utility classes.  Still, classes full of related static methods do have their place.

Ultimately, I might decide I’ve got my method belonging to the right class.  Static methods do give a slight performance benefit in certain cases, so at that point, it’s usually a good idea to make the method static if it doesn’t hurt anything.  But this should be your last option as a result of a deliberate design decision; the fact that you can make a particular method static should be just the start of a conversation about the possibilities.

  One Response to “Catchin’ Static”

  1. If it allows debug-and-continue in code that contains lambda expressions, I’ll jump ship from VS right now.

 Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>