Ci sono scenari in cui non dovremmo scrivere assegni difensivi per null?
Dovremmo scrivere codice difensivo o controllare NULL ogni volta che abbiamo passato un parametro o ricevuto un valore da un metodo?
Questo comporterà un onere aggiuntivo sul compilatore?
Il modo ideale per gestire i puntatori nulli è vietarli per contratto se un metodo non può gestirli. Dipende dal linguaggio quanto bene è supportato:
javax.validation.constraints.NotNull (o simili fornite da IDE come IntelliJ ed Eclipse) su qualsiasi parametro di metodo che non può essere nullo. Sfortunatamente, questo non è molto portabile. Contract.Requires( x != null ); . In genere, preferisco l'approccio al contratto piuttosto che cercare null in fase di esecuzione, se possibile. Abilita la scoperta degli errori in precedenza. Di solito, il controllo nullo basato su contratto genera anche un controllo di runtime in aggiunta al compilatore che tenta di dedurre se un parametro di una chiamata al metodo può violare il contratto in fase di compilazione.
Affermare che ci si fida del chiamante della propria libreria è una cattiva idea, perché non si sa mai se la libreria sarà riutilizzata in un altro ambiente. La fiducia nei chiamanti nuocerà sempre alla riusabilità del codice.
Leggi altre domande sui tag design c# architecture defensive-programming null