Dovrei sopprimere CA1062: argomenti Convalida dei metodi pubblici?

Question

Ho recentemente aggiornato il mio progetto a Visual Studio 2010 da Visual Studio 2008.

In Visual Studio 2008, questa regola di analisi del codice non esiste.

Ora io non sono sicuro se devo usare questa regola oppure no.

Sto costruendo una libreria open source così sembra importante mantenere le persone al sicuro dal fare errori. Tuttavia, se tutto quello che ho intenzione di fare è ArgumentNullException tiro quando il parametro è null, sembra che la scrittura di codice inutile dato ArgumentNullException sarà gettato anche se non voglio scrivere quel codice.

Modifica Inoltre, v'è un problema di prestazioni che deve essere affrontato. Controllando per null in ogni metodo pubblico può causare problemi di prestazioni.

Devo rimuovere quella regola o correggere le violazioni?

Answer 1

Beh dipende. La convenzione quando si utilizza ArgumentNullException è includere il nome dell'argomento nullo nella descrizione. Così il chiamante saprà esattamente cosa è andato storto.

La fonte di un NullReferenceException (che è ciò che accadrà se non lo fai validate) può essere facile da individuare, ma se il metodo è complesso, può essere più difficile. Si può finire in una riga di codice in cui più riferimenti potrebbero essere nulli.

Personalmente preferisco avere metodi pubblici lanciano ArgumentNullException se non riescono a gestire l'input nullo per l'argomento dato, perché permette di avere un comportamento coerente, non importa quanto il metodo è implementato.

In risposta a edit: A mio parere è più importante di fornire un insieme coerente di interfacce con poche sorprese rispetto a ottimizzare ogni riga di codice. La mia ipotesi è che nella maggior parte dei casi il sovraccarico delle prestazioni del controllo null non sarà significativo. Se non rivelarsi un problema (come nel profiling dice così) riterrei cambiarlo. Altrimenti non lo considererei un problema a questo punto.

Answer 2

a mantenere questa regola sul perché abbiamo deciso che era sempre meglio controllare i parametri sul loro primo ingresso nel codice. In questo modo, quando la persona che utilizza il codice ottiene l'eccezione del contesto in esso sarà migliore. Qualcuno che non ha il codice sorgente per esempio vedrà che l'eccezione è stato gettato nel codice e può presentare un bug report contro di voi perché sprecare il vostro tempo e la loro.

Answer 3

IMHO n Controllo di valori null non è quasi mai sarà il collo di bottiglia nella vostra applicazione. (E in uno in un caso in cui milioni è significativo, lo troverete con il profiler e rimuovere che un caso).

L'altra domanda che dovrebbe formare nella vostra mente è "è gettare nuova NullReferenceException () davvero il modo migliore per gestire l'errore?" Spesso è possibile gestire le cose meglio di così (anche se solo per fornire una migliore rapporto di errore per l'utente e / o di voi stessi per scopi di debug). In molti casi il codice in grado di gestire i null con grazia, rendendo inutile per questo di essere un errore a tutti.

modifica

Per rispondere alla tua edit: controlli Null davvero non richiede molto tempo. L'overhead semplicemente per chiamare un metodo sarà decine se non centinaia di volte più di un assegno nullo. L'unico posto dove un assegno nulla farà alcuna differenza significativa è in un grande, loop stretto in cui si sta facendo molto poco altro. Questa situazione non accade molto spesso -. Di solito si verifica per un nulla e poi fare qualcosa relativamente costosi con quello di riferimento

Non v'è alcuna situazione in cui un incidente o il fallimento è una buona cosa. E 'sempre meglio a "rallentare il basso applicazione" con controlli nulli rispetto a crash e perdere i dati del vostro cliente.

Quindi non prematuramente ottimizzare il codice. Scrivere bene, per essere mantenibile e robusto, quindi profilo per vedere dove sono i colli di bottiglia. Sono stato di programmazione per 28 anni, essendo molto liberale con controlli nulli, e ho non ha rilevato che un controllo nulla è stata la causa di un problema di prestazioni. Di solito è le cose come facendo un sacco di lavoro inutile in un ciclo, usando un O (n ^ 3) algoritmo dove un O (n ^ 2) approccio è possibile, non riuscendo a memorizzare nella cache i valori costosi-to-calcolo, ecc.