analisi del codice comportamento regola CA1062

Question

Ho seguente metodo di estensione per le stringhe:

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

... e nel codice lo uso come segue:

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

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

    return target; 
} 

Ora, se corro analisi del codice su questo, ricevo una violazione della regola CA1062. Ma se cambio il codice per:

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; 
} 

... allora va bene.

Perché pensa che non sto verificando la condizione nulla nel primo esempio? Controlla solo string.IsNullOrEmpty o string.IsNullOrWhiteSpace? C'è un modo per far sì che CA riconosca il mio metodo di estensione o dovrò sopprimere questa regola?

UPDATE: Se avete lo stesso problema si può votare sulla voce feedback che ho presentato su MS Connect: Code Analysis rule CA1062 raises false alarm

Answer 1

Perché pensa che non sto controllando per la condizione nullo nel primo esempio?

Molto semplicemente, FxCop non capisce che se il tuo metodo di estensione IsNullOrEmpty fa la stessa cosa come string.IsNullOrEmpty. Non si rende conto che se target è nullo, IsNullOrEmpty restituirà true e il metodo verrà chiuso. Fondamentalmente sospetto che abbia una conoscenza integrata di string.IsNullOrEmpty. Code Contracts è più probabile che abbia successo qui, poiché ritengo che FxCop esegua solo un controllo relativamente superficiale su ciò che fa il tuo codice, rispetto al ragionamento profondo dei Contratti di Codice. Potresti decorare il tuo metodo IsNullOrEmpty con ValidatedNotNullAttribute per informare FxCop su cosa sta succedendo.

public static bool IsNullOrEmpty([ValidatedNotNullAttribute] this string target) 
{ 
    return string.IsNullOrEmpty(target); 
} 
//The naming is important to inform FxCop 
sealed class ValidatedNotNullAttribute : Attribute { } 

Questo è solo un esempio di dove l'analisi del codice a volte può essere un po 'troppo ansiosa di criticare. È qualcosa che ho visto con praticamente tutti gli strumenti di analisi del codice che ho usato. Le scelte sono di solito lungo le linee di:

• modificare il codice per aggirare lo strumento di analisi del codice, anche se tutto è andato bene prima
• reprimere le regole in siti specifici, dopo aver verificato manualmente ciascuno di essi
• Sopprimere regole intere se spesso danno falsi positivi
• Abbandonare lo strumento di analisi del codice del tutto

Si dovrebbe anche registrare una richiesta di bug o funzionalità, naturalmente ...