Code Inspection: Member can be made static(shared) (non-private accessibility)

This is a solution-wide code inspection. It only works when the Solution-wide analysis is enabled.

Consider the method Print below:

  public class Foo
  {
    public void Test()
    {
      Print("John");
    }

    public void Print(string name)
    {
      Console.WriteLine("Hello, {0}!", name);
    }
  }
            

Public Class Foo
    Public Sub Test()
        Print("John")
    End Sub

    Public Sub Print(name As String)
        Console.WriteLine("Hello, {0}!", name)
    End Sub
End Class
            

If solution-wide analysis is enabled, ReSharper suggests that Print has no instance usages and can be made static. But what’s the point? Well, as it turns out, static members yield a small performance benefit under particular circumstances.

Here’s what the MSDN documentation has to say about it:

- Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

For the solution-wide inspection to work, you need either or both of the following:

The simplified global usage checking is enabled — Show unused non-private type members when solution-wide analysis is off on the Code Inspection | Settings page of ReSharper options (Alt+R, O).
The solution-wide analysis is enabled — Enable solution-wide analysis on the Code Inspection | Settings page of ReSharper options (Alt+R, O).

Note that even if a symbol has no direct usages in your solution and ReSharper warns you about it, there could be cases where symbols are used indirectly — for example, via reflection — or they could just be designed as public API. In all those cases you would want to suppress the usage-checking inspection for the symbol, and there are several ways to do so:

The recommended way is to decorate the implicitly used symbols with code annotation attributes. There are two attributes for this purpose: [UsedImplicitly] and [PublicAPI], which are functionally similar, but let you and your teammates understand how the symbol is actually used.
You can also suppress usage-checking inspections with any custom attribute. To do so, mark the definition of that attribute with the [MeansImplicitUse] attribute.
And finally, you can suppress a specific usage-checking inspection as any other code inspection with a suppression comment or a suppression attribute.

Last modified: 29 June 2021