LowFile-scopeC# Plug & play

Utility Classes Should Not Have Public Constructors

Utility classes are not meant to be instantiated. Mark them as static or provide a private constructor to prevent unintended instantiation.

Add to Mesrai Open workspace

Why this matters

Utility classes are not meant to be instantiated. Mark them as static or provide a private constructor to prevent unintended instantiation.

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

public class StringUtils // Noncompliant: implicit public constructor
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Prefer

public static class StringUtils // Compliant: the class is static
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}


public class StringUtils // Compliant: the constructor is not public
{
  private StringUtils()
  {
  }

  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

More snippets

Bad

public class StringUtils // Noncompliant: implicit public constructor
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Good

public static class StringUtils // Compliant: the class is static
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}


public class StringUtils // Compliant: the constructor is not public
{
  private StringUtils()
  {
  }

  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Related rules

From the same buckets as this rule.

Critical
Avoid Duplicating String Literals
Store repeated string literals in constants or variables to improve maintainability and reduce redundancy.
duplication-complexitymaintainability
Critical
Avoid Empty Methods
Detect methods that have an empty body. If a method is empty, ensure that a comment is present explaining why it remains unimplemented.
maintainabilityreadability-refactor
Critical
Avoid modifying built-in prototypes
Detect modifications to built-in prototypes. Modifying built-in objects can lead to compatibility issues and unexpected behavior. Recommend creating helper functions instead.
maintainabilitysecurity-hardening

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

public class StringUtils // Noncompliant: implicit public constructor
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Prefer

public static class StringUtils // Compliant: the class is static
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}


public class StringUtils // Compliant: the constructor is not public
{
  private StringUtils()
  {
  }

  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

More snippets

Bad

public class StringUtils // Noncompliant: implicit public constructor
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Good

public static class StringUtils // Compliant: the class is static
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}


public class StringUtils // Compliant: the constructor is not public
{
  private StringUtils()
  {
  }

  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Related rules

From the same buckets as this rule.

Critical

Avoid Duplicating String Literals

Store repeated string literals in constants or variables to improve maintainability and reduce redundancy.

duplication-complexitymaintainability

Critical

Avoid Empty Methods

Detect methods that have an empty body. If a method is empty, ensure that a comment is present explaining why it remains unimplemented.

maintainabilityreadability-refactor

Critical

Avoid modifying built-in prototypes

Detect modifications to built-in prototypes. Modifying built-in objects can lead to compatibility issues and unexpected behavior. Recommend creating helper functions instead.

maintainabilitysecurity-hardening