Good reasons for static methods?

Question

I use static methods for things I really MEANT to be static. I use ReSharper for better code quality. Sometimes ReSharper suggests that a method can be made static.

When I got the following class:

public class WhatEverClass {
    private string DoSomethingFancy(string input) 
    {
       string fancyStuff;
       // Fancy Stuff here
       return fancyStuff;
    }

    public WhatEverClass() {
       string awesome=DoSomethingFancy("some fancy string");
    }
}

ReSharper might say "DoSomethingFancy can be made static".

I know it could be made static, but is there a good reason to really do this? Or should I just ignore these suggestions?

possible duplicate of [ReSharper complains when method can be static, but isn't](http://stackoverflow.com/questions/790281/resharper-complains-when-method-can-be-static-but-isnt) — Adriaan Stander, Jun 26 '13 at 11:46
I think you should not mark it as static unless you are 100% certain the method will not require state at some point. — vc 74, Jun 26 '13 at 11:49
another similar - http://stackoverflow.com/questions/7021054/why-does-resharper-suggest-const-static-operations — NDJ, Jun 26 '13 at 11:50
@astander I don't think its a duplicate. The linked article is a very general question. Mine has a specific example and the wish why this one should be made static — Ole Albers, Jun 26 '13 at 12:02

score 6 · Accepted Answer · answered Jun 26 '13 at 11:43

By defining a method static, so a procedure that computes something, you manifest an intent to a consumer of your API about statelessness of your function.

When we use static function, we do not expect it saves a state of computation or some computed internal value somewhere in it's internal static private variables, so the next call to that function may have different result even with the same parameters passed during the first call.

In short: whenever you see a function that just executes an action over parameter and not preserve some state, it is a good candidate for making it static.

+1 for actually providing some useful reasoning behind this, and not just a variant of "use static if you don't explicitly need something else...". — Kjartan, Jun 26 '13 at 11:51

score 1 · Answer 2 · answered Jun 26 '13 at 11:45

1

If your method doesn't need to say or change the state of an instanciated object, then it should be static.

answered Jun 26 '13 at 11:45

cbelizon

234
2
13

TypeMock have the capability of doing test to static methods. But yes, static methods are a huge problem with unit testing. – cbelizon Jun 26 '13 at 11:51
Correct me if I am wrong, but private static methods should not (negativly) effect unit tests at all? – Ole Albers Jun 26 '13 at 12:07
1

If the static method doesn't change states of other classes it would not be any problem with the unit test. If the method is called from another classes it is not a unit test, it's more like integrtion testing. – cbelizon Jun 26 '13 at 14:29

score 1 · Answer 3 · answered Jun 26 '13 at 11:47

The usual notion is , if you are not creating an instance of anything, you could declare it static. As to where it should be used, ReSharper gives you suggestions based on standard programming practices. However, i take 'standard programming practices' with a grain of salt. Its a matter of personal programming preference for some. Here is a detailed reference on the topic :

http://msdn.microsoft.com/en-us/library/79b3xss3.aspx

score 0 · Answer 4 · answered Jun 26 '13 at 11:44

0

Because you will invoke the WhatEverClass() method from outside the class by creating WhatEverClass instance. So the value for every instance will be different, because the variable is local, and will be created every time you create an instance of the class.

But if you want to keep the same value for all instances, then you can make it static so it will be created once in a memory and all instances will use it.

answered Jun 26 '13 at 11:44

Shaharyar

12,254
4
46
66

Sorry. But it is not about static values here. – Ole Albers Jun 26 '13 at 12:00

score 0 · Answer 5 · answered Jun 26 '13 at 12:01

0

Beware the consequences of making a method static!

By making your method static, you make it that much harder for consumers to stub out your implementation of the algorithm and replace it with one of their own (obviously if the method is private you have no such worries).

Consumers of your static method have your implementation baked in to their code - they cannot use dependency injection to resolve a specific instance of your algorithm (without a bit of work). This makes their system that much harder to test, and in general lends itself to a less extensible code base.

answered Jun 26 '13 at 12:01

Lawrence

3,287
19
32

I do not want do provide a framework or something like that. It is a project for a customer where I and team members have the source but no one "outside" will use it as a source for something else – Ole Albers Jun 26 '13 at 12:04
You always have consumers - whether you consider them to be external or not. The primary application, as well as the test harness are two consumers with different requirements. What if your test harness wants to test an aspect of your system without using the specific implementation of your algorithm? The other members of your team will be consuming your code - yes? – Lawrence Jun 26 '13 at 12:07

score -1 · Answer 6 · answered Jun 26 '13 at 11:43

-1

If the method DoSomethingFancy does not use anything in the object WhatEverClass then it should, in my book, be made static since it does not in fact have anything to do with the object in which it is used.

answered Jun 26 '13 at 11:43

Sander

1,264
1
16
26

The problem is that you can not test methods that use your static function ever. You can't mock the static function, which is a big problem. – David Aug 11 '19 at 18:20

Good reasons for static methods?

6 Answers6