Code-Analyse-Regel CA1062 Verhalten

Question

Ich habe folgende Erweiterungsmethode für Strings:

public static bool IsNullOrEmpty(this string target) 
{ 
    return string.IsNullOrEmpty(target); 
} 

... und in dem Code, den ich es wie folgt verwenden:

public static string DoSomethingOnString(this string target) 
{ 
    if (target.IsNullOrEmpty()) 
     return target; 

    target = target.Trim(); //This line causes CA1062 violation 

    return target; 
} 

Nun, wenn ich Code-Analyse ausführen Ich bekomme einen Verstoß gegen die Regel CA1062. Aber wenn ich den Code zu ändern:

public static string DoSomethingOnString(this string target) 
{ 
    if (string.IsNullOrEmpty(target)) //CHANGED LINE 
     return target; 

    target = target.Trim(); //This line DOES NOT cause CA1062 violation anymore 

    return target; 
} 

... dann ist es in Ordnung.

Warum denkt es, dass ich im ersten Beispiel nicht nach Null-Bedingung suche? Prüft es nur für string.IsNullOrEmpty oder string.IsNullOrWhiteSpace? Gibt es eine Möglichkeit, CA dazu zu bringen, meine Erweiterungsmethode zu erkennen, oder muss ich diese Regel unterdrücken?

UPDATE: Wenn Sie das gleiche Problem, das Sie auf dem Feedback Artikel stimmen kann ich auf MS Connect vorgelegt: Code Analysis rule CA1062 raises false alarm

Answer 1

Warum es denkt, dass ich nicht in der ersten für null Zustand bin Überprüfung Beispiel?

Ganz einfach, FxCop nicht versteht, dass, wenn Ihre IsNullOrEmpty Erweiterungsmethode macht das Gleiche wie string.IsNullOrEmpty. Es stellt nicht fest, dass, wenn target null ist, IsNullOrEmptytrue zurückgibt und Ihre Methode beendet wird. Grundsätzlich vermute ich, dass es ein eingebautes Wissen von string.IsNullOrEmpty hat. Code Contracts ist hier eher erfolgreich, da ich glaube, dass FxCop nur eine relativ oberflächliche Überprüfung dessen durchführt, was Ihr Code tut, verglichen mit der tiefen Argumentation von Code-Verträgen. Sie können Ihre IsNullOrEmpty Methode mit ValidatedNotNullAttribute dekorieren, um FxCop darüber zu informieren, was vor sich geht.

Dies ist nur ein Beispiel, wo Code-Analyse manchmal ein wenig zu eifrig sein kann, zu kritisieren. Es ist etwas, das ich mit so ziemlich jedem Codeanalyse-Tool gesehen habe, das ich verwendet habe. Ihre Entscheidungen sind in der Regel entlang der Linien von:

Code ändern
• um das Code-Analyse-Tool zu arbeiten, auch wenn es vor
• Unterdrückt die Regeln an bestimmten Stellen in Ordnung war, nachdem manuell jeder von ihnen überprüft
• Suppress ganze Regeln, wenn sie häufig falsch positive Ergebnisse geben
• Abandon den Code-Analyse-Tool vollständig

Sie auch einen Bug oder Feature-Request einloggen sollte natürlich ...