Static vs. non-static method
Suppose you have some method that could be made static, inside a non-static class.
For example:
private double power(double a, double b)
{
return (Math.Pow(a, b));
}
Do you see any benefit from changing the method signature into static? In the example above:
private static double power(double a, double b)
{
return (Math.Pow(a, b));
}
Even if there is some performance or memory gain, wouldn't the compiler do it as a simple optimization in compile time?
Edit: What I am looking for are the benefits by declaring the method as static. I know that this is the common practice. I would like to understand the logic behind it.
And of course, this method is just an example to clarify my intention.
Solution 1:
As defined, power is stateless and has no side effects on any enclosing class so it should be declared static.
This article from MSDN goes into some of the performance differences of non-static versus static. The call is about four times faster than instantiating and calling, but it really only matters in a tight loop that is a performance bottleneck.
Solution 2:
There should be a slight performance improvement if you declare the method static, because the compiler will emit a call IL instruction instead of callvirt.
But like the others said, it should be static anyway, since it is not related to a specific instance
Solution 3:
Note that it is highly unlikely the compiler is even allowed to make that change on your behalf since it changes the signature of the method. As a result, some carefully crafted reflection (if you were using any) could stop working, and the compiler really cannot tell if this is the case.
Solution 4:
Do you see any benefit from changing the method signature into static?
Three benefits:
Making stateless methods static helps document and clarify their purpose. Otherwise, one is inclined to worry just what mysterious state does the method depend upon?
The static method can be called from other static code, so is potentially more useful.
Static method calls have a smidgin less runtime overhead than instance ones. The compiler can't do that transform automatically -- one reason why is because it would affect use of null. Calling the method on a null reference is required to fail with a NullReferenceException, even if there is no instance state used within the method.