Debug.Assert e Debug.Fail dovrebbero essere utilizzati liberamente e dovrebbero essere lasciati nel codice di produzione?

Question

Io sto leggendo un libro che afferma (gioco di parole) "è necessario caricare il codice con Debug.Assert metodi ovunque ci sia una condizione che sarà sempre vero o falso."

Non ho usato questi due metodi di debug, ma ha un senso. Tuttavia, sono dispiaciuto che questa roba sia disseminata per tutto il mio codice di produzione.

Pensieri?

Answer 1

Va bene, poiché il compilatore lo omette in release build. Non è una cattiva pratica e non è necessario rimuoverli dalla fonte (in effetti, probabilmente non dovresti). Ma si necessario attenzione:

Debug.Assert(SomethingImportantThatMustExecute()); 

è cattivo - il SomethingImportantThatMustExecute saranno ignorate nel rilascio; è necessario utilizzare:

bool result = SomethingImportantThatMustExecute() 
Debug.Assert(result); 

Fondamentalmente, evitare effetti collaterali in chiamate ai metodi condizionali e metodi parziali.

Answer 2

Se si compila una build di rilascio (utilizzando l'impostazione del progetto di Visual Studio), tutte le istruzioni Debug.Assert verranno automaticamente rimosse. Quindi sì, usali liberamente.

Answer 3

È possibile utilizzare Debug.Assert liberamente nelle basi di codici di produzione. Debug.Assert è decorato con ConditionalAttribute. Se si compila il codice nella configurazione "rilasciare", il compilatore salterà chiamando Debug.Assert.

Answer 4

Dipende da cosa lo stai usando. Se la stai usando per asserzioni con i tuoi stessi metodi, per assicurarti che funzionino correttamente, penso che sia okay - ma preferirei test unitari per convalidare tutto quello che posso pensare se possibile.

È non una buona idea (IMO) da utilizzare per convalidare l'input in entrata - ad es. parametri. In questo caso credo che sia molto più consistente di utilizzare le eccezioni in modo normale di:

if (foo == null) 
{ 
    throw new ArgumentNullException("foo"); 
} 

A mio avviso questo comportamento dovrebbe non cambiamento solo perché si sta eseguendo codice di rilascio.

Answer 5

Sì, le affermazioni vanno bene. E si noti che non sono solo dei controlli logici (è ovvio), ma servono anche come una forma di documentazione, più affidabile dei commenti.

Ma pensate in anticipo ai test unitari. Se hai intenzione di testare i risultati del debug, i risultati (rispetto alla logica degli errori) possono essere diversi dalla versione di rilascio.

Per i controlli che si desidera attivare nella build di rilascio è possibile utilizzare Trace.Assert().

E nessuno ha menzionato lo Code Contracts, un modo più ricco e strutturato di controllare e documentare il codice.