ReSharper Curiosity: "Le paramètre n'est utilisé que pour le (s) contrôle (s) des conditions préalables."

Pourquoi ReSharper me juge pour ce code?

    private Control GetCorrespondingInputControl(SupportedType supportedType, object settingValue)
    {
        this.ValidateCorrespondingValueType(supportedType, settingValue);

        switch(supportedType)
        {
            case SupportedType.String:
                return new TextBox { Text = (string)settingValue };
            case SupportedType.DateTime:
                return new MonthPicker { Value = (DateTime)settingValue, ShowUpDown = true };
            default:
                throw new ArgumentOutOfRangeException(string.Format("The supported type value, {0} has no corresponding user control defined.", supportedType));
        }
    }

    private void ValidateCorrespondingValueType(SupportedType supportedType, object settingValue)
    {
        Type type;

        switch(supportedType)
        {
            case SupportedType.String:
                type = typeof(string);
                break;
            case SupportedType.DateTime:
                type = typeof(DateTime);
                break;
            default:
                throw new ArgumentOutOfRangeException(string.Format("The supported type value, {0} has no corresponding Type defined.", supportedType));
        }
        string exceptionMessage = string.Format("The specified setting value is not assignable to the supported type, [{0}].", supportedType);
        if(settingValue.GetType() != type)
        {
            throw new InvalidOperationException(exceptionMessage);
        }
    }

Le paramètre "settingValue" de la deuxième méthode ValidateCorrespondingValueType est grisé avec le message suivant de ReSharper: "Le paramètre" settingValue "est uniquement utilisé pour les vérifications de précondition."

Ce n'est pas de juger, c'est d'essayer d'aider :)

Si ReSharper voit qu'un paramètre n'est utilisé que comme contrôle pour lever une exception, il le grise, indiquant que vous ne l'utilisez pas réellement pour un travail "réel". C'est probablement une erreur - pourquoi passer un paramètre que vous n'allez pas utiliser? Cela indique généralement que vous l'avez utilisé dans une condition préalable, mais que vous avez ensuite oublié (ou n'avez plus besoin) de l'utiliser ailleurs dans le code.

Étant donné que la méthode est une méthode d'assertion (c'est-à-dire qu'elle ne fait qu'affirmer qu'elle est valide), vous pouvez supprimer le message en marquant ValidateCorrespondingValueTypecomme méthode d'assertion, en utilisant les attributs d'annotation de ReSharper , en particulier l' [AssertionMethod]attribut:

[AssertionMethod]
private void ValidateCorrespondingValueType(SupportedType supportedType, object settingValue)
{
  // …
}

Fait intéressant, ReSharper recule si vous utilisez la nouvelle nameoffonctionnalité en C # 6:

static void CheckForNullParameters(IExecutor executor, ILogger logger)
{
    if (executor == null)
    {
        throw new ArgumentNullException(nameof(executor));
    }

    if (logger == null)
    {
        throw new ArgumentNullException(nameof(logger));
    }
}

Ce qui suit résout le problème (dans ReSharper 2016.1.1, VS2015), mais je ne suis pas sûr que cela résout le «bon» problème. Dans tous les cas, cela montre l'ambiguïté dans la mécanique de ReSharper concernant ce sujet:

Cela donne l'avertissement:

    private void CheckForNull(object obj)
    {
        if (ReferenceEquals(obj, null))
        {
            throw new Exception();
        }
    }

Mais cela ne fait pas:

    private void CheckForNull(object obj)
    {
        if (!ReferenceEquals(obj, null))
        {
            return;
        }
        throw new Exception();
    }

Il est intéressant de noter qu'un code équivalent (l'inversion a été faite par ReSharper: D) donne des résultats différents. Il semble que la correspondance de motifs ne reprend tout simplement pas la deuxième version.

Ma solution préférée à ce problème est de faire en sorte que resharper pense que le paramètre est utilisé. Cela a un avantage par rapport à l' aide d' un attribut tel que UsedImplicitlyparce que si jamais vous ne en utilisant ce paramètre arrêt, ReSharper commencera à vous avertir à nouveau. Si vous utilisez un attribut, le resharper ne captera pas non plus les futurs avertissements réels.

Un moyen simple de faire en sorte que resharper pense que le paramètre est utilisé consiste à le remplacer throwpar une méthode. Alors au lieu de ...

if(myPreconditionParam == wrong)
    throw new Exception(...);

...vous écrivez:

if(myPreconditionParam == wrong)
    new Exception(...).ThrowPreconditionViolation();

Ceci est bien auto-documenté pour les futurs programmeurs, et le resharper arrête de pleurnicher.

L'implémentation de ThrowPreconditionViolation est triviale:

public static class WorkAroundResharperBugs 
{
    //NOT [Pure] so resharper shuts up; the aim of this method is to make resharper 
    //shut up about "Parameter 'Foobaar' is used only for precondition checks" 
    //optionally: [DebuggerHidden]
    public static void ThrowPreconditionViolation(this Exception e)
    {
        throw e;
    }
}

Une méthode d'extension sur Exception est la pollution de l'espace de noms, mais elle est assez contenue.

D'autres ont déjà répondu à la question, mais personne n'a mentionné les façons suivantes de désactiver l'avertissement.

Ajoutez ceci au-dessus de la signature de la méthode pour la désactiver uniquement pour cette méthode:

    // ReSharper disable once ParameterOnlyUsedForPreconditionCheck.Local

Ajoutez ceci au-dessus de la déclaration de classe pour la désactiver pour tout le fichier:

     // ReSharper disable ParameterOnlyUsedForPreconditionCheck.Local