Workaround for SonarQube's complaint for When implementing IComparable<T> or IComparable, you should also override <, <=, >, and >=.

[tavanuka]

Hello everyone,
I am working on a project that is utilising the SonarQube static analyser and we have decided to roll with the VoGen and use them for our aggregates.
pretext: the following defaults are configured in the domain project with VoGen version 8.0.5

[assembly: VogenDefaults(
    staticAbstractsGeneration: StaticAbstractsGeneration.MostCommon, customizations: Customizations.AddFactoryMethodForGuids)]

all fine and dandy. However, for some VO's we get static analysis warnings for maintainability issue given by SonarQube:

Equals" and the comparison operators should be overridden when implementing "IComparable"
When implementing IComparable or IComparable, you should also override <, <=, >, and >=.
csharpsquid:S1210

Description of the rule:

When you implement IComparable or IComparable on a class you should also override Equals(object) and overload the comparison operators (==, !=, <, <=, >, >=). That’s because the CLR cannot automatically call your CompareTo implementation from Equals(object) or from the base comparison operator implementations. Additionally, it is best practice to override GetHashCode along with Equals.
This rule raises an issue when a class implements IComparable without also overriding Equals(object) and the comparison operators.

Could this possibly be bypassing these?

/ Suppress warnings for 'Override methods on comparable types'.
#pragma warning disable CA1036
// Suppress Error MA0097 : A class that implements IComparable<T> or IComparable should override comparison operators
#pragma warning disable MA0097

Because clearly the source generated files provide some comparison operators, but not all.

What would be a good solution around this besides accepting it in SonarCloud?
Thanks in advance!

[SteveDunn]

Hi, thanks for the question. It might be possible in Sonar to skip analysing compiler generated files. I'll take a look at this when time permits.
Thanks again for the question!

[tavanuka]

I appreciate for your response. I will look into the analysis skip as well. I will also double check whether Rider also complains about it (which it should not) and on top of that try out the local setup with a local sonarqube.

[tavanuka]

[ValueObject<string>]
public readonly partial struct PermissionKey
{
    public const int MaxLength = 100;

    [GeneratedRegex("^[a-z]+(-[a-z]+)*(:[a-z]+(-[a-z]+)*)+$")]
    private static partial Regex Format();

    private static string NormalizeInput(string input) => input.Trim().ToLowerInvariant();

    private static Validation Validate(string input)
    {
        if (string.IsNullOrWhiteSpace(input))
            return Validation.Invalid(nameof(DomainValidationResources.Required));
        if (input.Length > MaxLength)
            return Validation.Invalid(nameof(DomainValidationResources.TooLong)).WithData("max", MaxLength);
        return Format().IsMatch(input)
            ? Validation.Ok
            : Validation.Invalid(nameof(DomainValidationResources.InvalidFormat));
    }

   // Here onwards -> these overloads and definitions satisfy the analysis from SonarQube
    public static bool operator <(PermissionKey left, PermissionKey right)
        => left.CompareTo(right) < 0;

    public static bool operator <=(PermissionKey left, PermissionKey right)
        => left.CompareTo(right) <= 0;

    public static bool operator >(PermissionKey left, PermissionKey right)
        => left.CompareTo(right) > 0;

    public static bool operator >=(PermissionKey left, PermissionKey right)
        => left.CompareTo(right) >= 0;
}

I realized that implementing these operator functionalities satisfies the complaints thrown by SonarQube. could there be an opt-in flag or alike for these operations if they are meant to be this simple?

Or potentionally leave the door open for overrides?