C# String.IsNullOrEmpty: buono o cattivo?

Question

Dopo un incidente sul posto di lavoro dove ho abusato String.IsNullOrEmpty con una variabile di sessione, un collega collega di mine ora rifiuta di accettare il mio utilizzo di String.IsNullOrEmpty. Dopo alcune ricerche, a quanto pare c'è un bug elencato per IsNullOrEmpty su MSDN (link) (vedi nota in fondo):

A partire dal 4 Aprile 2006, c'è un bug (possibile nel JIT) che fa questo metodo fallisce quando le ottimizzazioni sono attivate. È noto che influisce sia su C# sia su VB.

Ulteriori informazioni possono essere trovate qui (link). Microsoft il bug è "apparentemente" fisso post-Orche, ma sfortunatamente il mio datore di lavoro usa ancora VS2005. Ma se il problema è stato risolto nel 2008+ così sia. Va bene con me.

Mentre il rifiuto del mio collega del mio codice con IsNullOrEmpty per me è cieca ignoranza (IMO) di certo non può dirmi perché non da usare in altro modo che l'uso improprio con la variabile di sessione. Ho usato IsNullOrEmpty su tutto il nostro codice senza problemi di sorta. Personalmente, lo trovo molto più leggibile oltre a fare due cose in una dichiarazione.

Dopo googling per pareri in materia, ho i siti che prendono il pro/con posizione trovato. Ecco alcuni dei siti che ho letto su questo:

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

Un sito (http://dotnetperls.com/isnullorempty) riassume il metodo (IMHO) piuttosto bene:

Qui sembrava che IsNullOrEmpty metodo del tipo stringa, che ci fornisce un metodo efficiente relativamente buona e di verificare se unLa stringapuò essere salvata o utilizzata. Tuttavia, per le prestazioni, potrebbe essere preferibile eseguire utilizzando controlli null manuali. Le stringhe vuote possono essere testati in altri modi, e mia ricerca qui dimostra che il controllo lunghezza è più veloce.

Assumendo che la correzione di bug è a posto (e funziona correttamente) in VS2008/2010/ecc., Non v'è alcun motivo per non utilizzare String.IsNullOrEmpty con VS2005 e oltre? Mi rendo conto che questo può sembrare un po 'eccessivo rispetto a un metodo così sciocco, ma mi piacerebbe sapere se c'è più dietro le quinte e se qualcuno ha spiegazioni alternative.

Answer 1

Questo problema è stato risolto in .NET 2.0 SP1. Non c'è motivo di evitarlo ora.

Se stai usando .NET 2, si dovrebbe avere SP1 per molte altre ragioni in ogni modo - non vedo alcuna ragione per evitare questo per un bug che non esiste più.

Answer 2

Se si è rotto nella versione, allora è banale di avere solo un metodo statico che farà il controllo, quindi basta fare:

public static bool isNull(String s) { 
    return s == null || s.trim().length == 0; 
} 

Inutile entrare in un grande problema su qualcosa che dovrebbe essere relativamente facile da risolvere.

Non è necessario cambiarlo ovunque, anche se è possibile eseguire una sostituzione globale di un metodo statico con un altro.

Answer 3

si potrebbe scrivere uno unit test che passa una stringa vuota e uno che passa una stringa nulla per testare questa roba, ed eseguirlo in VS2005 e dopo nel 2008 e vedere cosa è successo

Answer 4

In tale relazione bug nel link you include it states:

Questo bug è stato risolto nel Service Pack 1 (SP1) di Microsoft .NET Framework 2.0.

Poiché questo è il caso, non importa se si utilizza VS 2005 fino a quando SP1 per .NET 2 è installato.

Per quanto riguarda se usarlo o meno, dai un'occhiata a questo post by CodingHorror.

Answer 5

io sono abbastanza sicuro che è stato fissato sulla SP1, ma in ogni caso è possibile creare il proprio nullo o metodo vuoto :)

Answer 6

Come con qualsiasi lingua o parte di esso, è tutto di conoscere i pro/contro e facendo un decisione istruita basata su quella informazione. A PARER MIO.

Answer 7

Usiamo un metodo di estensione per string.IsNullOrEmpty:

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

Usando questo approccio, anche se fosse rotto in qualche versione precedente, un bugfix è solo una riga di codice.

E il valore aggiunto di essere in grado di utilizzare il metodo su un'istanza stringa che potrebbe essere nullo:

string myString = null; 
if (myString.IsNullOrEmpty()) 
{ 
    // Still works 
} 

Answer 8

Ho sentito parlare di quel bug prima, e da quello che ho potuto capire che non si verifica mai in qualsiasi codice reale, solo nel codice come nell'esempio che in realtà non fa nulla. Inoltre, il bug non è con il metodo IsNullOrEmpty stesso, quindi si verificherà indipendentemente da come si controlla la stringa.

Se il metodo esegue esattamente ciò che si desidera, è necessario utilizzarlo. Tuttavia, non dovresti usarlo in ogni situazione per controllare una stringa vuota. A volte vuoi solo controllare se la stringa è vuota e non se è nulla.

Se la variabile stringa è nulla, questo sarà solo saltare il blocco di codice:

if (!String.IsNullOrEmpty(str)) { ... } 

Se la variabile stringa è nulla, ciò causerà un'eccezione:

if (str.Length > 0) { ... } 

Se la variabile è non supposto essere nullo, probabilmente si desidera l'eccezione al posto del codice che considera il valore nullo come una stringa vuota.Se qualcosa non va, lo vuoi catturare il prima possibile, perché sarà più difficile rintracciare il problema alla fonte più a lungo l'eccezione deriverà dalla causa.

Answer 9

Mi chiedo perché la gente usa string.Empty, non è una buona cosa, perché è una stringa inizializzata & questo concetto esiste solo in Net telaio in tutto il mondo questa è una stringa valida con len di 0 (DB server rendono molto chiaro destinction tra questo e si lamenterà se si ha il controllo logico di null ma si ottiene e si svuota la stringa). Penso che string.IsNullOrEmpty sia una delle 5 migliori pratiche/funzioni peggiori che io abbia mai visto, perché in qualche modo incoraggia/fa apparire ok le persone che iniziano le loro stringhe e può essere trattato come null. Questa funzione non dovrebbe mai essere stata aggiunta e penso che i ragazzi di .Net dovrebbero provare a eliminarlo :) Chi ha bisogno e vuol stringere comunque? Non l'ho mai usato a meno che non fosse necessario a causa di progetti esistenti.

Answer 10

Quando si implementa il controllo degli argomenti nelle API, di solito controllo ogni condizione separatamente e faccio eccezioni diverse: ArgumentNullException per un riferimento null o, in base all'API specifiche, ArgumentException per una stringa vuota. In questo caso, l'utilizzo di String.IsNullOrEmpty non consente di distinguere tra queste due condizioni di errore separate.

if (str == null) 
{ 
    throw new ArgumentNullException("str"); 
} 
if (str == string.Empty) 
{ 
    throw new ArgumentException("The string cannot be empty.", "str"); 
}