S2325 — Methods and properties that don't access instance data should be static

Why is this an issue?

A method or property that does not access instance data can often be static. This makes its independence from a particular object explicit and lets callers use it without creating an instance. Add static when the member’s API and framework contracts allow it.

Changing a public instance member to static changes how callers access it and can break existing consumers. Keep instance members when required by an interface, override, or framework callback contract.

Noncompliant code example

public class Utilities
{
    public int Sum(int a, int b) // Noncompliant: uses only its parameters
    {
        return a + b;
    }
}

Compliant solution

public class Utilities
{
    public static int Sum(int a, int b)
    {
        return a + b;
    }
}

Call the corrected method as Utilities.Sum(a, b). The same reasoning applies to properties that return a constant or access only static fields. A static member can still use shared mutable state; making it static does not make it pure or thread-safe.

Exceptions

Methods with the following names are excluded because the framework expects instance methods:

• Application_AuthenticateRequest
• Application_BeginRequest
• Application_End
• Application_EndRequest
• Application_Error
• Application_Init
• Application_Start
• Session_End
• Session_Start

Event handler methods part of a Windows Forms, Windows Presentation Foundation or .NET MAUI class are also excluded by this rule.

Resources

Documentation

• Microsoft Learn - The static modifier