C# String.IsNullOrEmpty: ¿bueno o malo?

Question

Después de un incidente en el trabajo en el que utilicé Mal uso de String.IsNullOrEmpty con una variable de sesión, un compañero de trabajo mío ahora se niega a aceptar mi uso de String.IsNullOrEmpty. Después de algunas investigaciones, al parecer hay un error enumerado para IsNullOrEmpty en MSDN (link) (leer nota al final):

Hasta el 4 de abril de 2006, hay un error (posible en el ECI) que hace este método falla cuando las optimizaciones están activadas . Se sabe que afecta tanto a C# como a VB.

Más información se puede encontrar aquí (link). Microsoft, el error es 'supuestamente' fijo después de Orcas, pero desafortunadamente mi empleador todavía usa VS2005. Pero si el problema se soluciona en 2008+, que así sea. Eso está bien conmigo.

Mientras que la negativa de mi colega de mi código con IsNullOrEmpty para mí es ciega ignorancia (OMI) que ciertamente no puede decirme por qué no de usar que no sea el mal uso de la variable de sesión. He usado IsNullOrEmpty en todo nuestro código sin problemas. Personalmente, me resulta mucho más legible además de hacer dos cosas en una declaración.

Después de buscar en Google las opiniones sobre el tema, he encontrado sitios que tienen los pros/la postura. Éstos son algunos de los sitios que he leído sobre esto:

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

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

un sitio (http://dotnetperls.com/isnullorempty) resume el método (en mi humilde opinión) bastante bien:

Aquí busqué ese método IsNullOrEmpty en el tipo de cadena, que nos proporciona un método bueno y relativamente eficiente de comprobar si un cadena está bien para guardar o usar. Sin embargo, para el rendimiento, puede ser mejor que use cheques nulos manuales. Las cadenas vacías también se pueden probar de otras formas, y mi investigación aquí muestra que la comprobación de es la más rápida.

Suponiendo la corrección de errores está en su lugar (y trabajando correctamente) en VS2008/2010/etc., ¿Hay alguna razón no utilizar String.IsNullOrEmpty con VS2005 y más allá? Me doy cuenta de que esto puede parecer un poco exagerado por un método tan tonto, pero me gustaría saber si hay más detrás de escena y si alguien tiene explicaciones alternativas.

Answer 1

Este problema se solucionó en .NET 2.0 sp1. No hay razón para evitar su uso ahora.

Si está utilizando .NET 2, debería tener sp1 por muchas otras razones de todos modos - No veo ninguna razón para evitar esto por un error que ya no existe.

Answer 2

Si se rompe en su versión, entonces es trivial para simplemente tener un método estático que va a hacer el registro de entrada, por lo que acaba de hacer:

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

No tiene sentido entrar en un gran problema por algo que debería ser relativamente fácil de arreglar

No necesita cambiarlo en todas partes, aunque puede hacer un reemplazo global de un método estático por otro.

Answer 3

se podría escribir una prueba unitaria que pasa una cadena vacía y uno que pasa una cadena nula para probar estas cosas, y ejecutarlo en VS2005 y un después en 2008 y ver lo que pasó

Answer 4

En ese informe de error en el enlace que incluya estados:

Este error se ha solucionado en el Microsoft .NET Framework 2.0 Service Pack 1 (SP1).

Dado que ese es el caso, no debería importar si está utilizando VS 2005 siempre y cuando tenga SP1 para .NET 2 instalado.

En cuanto a si usarlo o no, mira esto post by CodingHorror.

Answer 5

estoy bastante seguro de que se haya fijado en el SP1, pero de todos modos se puede crear su propio nulo o método vacío :)

Answer 6

Como con cualquier lenguaje o parte del mismo, se trata de conocer las ventajas/desventajas y hacer una decisión educada basada en esa información. EN MI HUMILDE OPINIÓN.

Answer 7

Utilizamos un método de extensión para string.IsNullOrEmpty:

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

uso de este enfoque, aunque fuese a la quiebra de alguna versión anterior, una corrección de errores es sólo una línea de código.

Y la utilidad añadida de ser capaz de utilizar el método en una instancia de cadena que podría ser nulo:

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

Answer 8

He oído hablar de ese error antes, y por lo que he entendido que nunca se encuentra cualquier código real, solo en código como el ejemplo que realmente no hace nada. Además, el error no está en el método IsNullOrEmpty en sí, por lo que ocurriría independientemente de cómo verifique la cadena.

Si el método hace exactamente lo que quiere hacer, debe usarlo. Sin embargo, no debes usarlo en todas las situaciones para verificar si hay una cadena vacía. A veces solo quieres comprobar si la cadena está vacía y no si es nula.

Si la variable de cadena es nula, esto acaba de saltar el bloque de código:

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

Si la variable de cadena es nula, esto causará una excepción:

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

Si la variable es no se supone que sea nulo, es probable que desee la excepción en lugar del código que trata el valor nulo como una cadena vacía.Si algo está mal, quiere detectarlo lo antes posible, porque será más difícil rastrear el problema hasta la fuente, mientras más larga sea la excepción de la causa.

Answer 9

Me pregunto por qué la gente usa string.Empty, no es algo bueno porque es una cadena inicializada & este concepto existe solo en .Net frame en todas partes es una cadena válida con len de 0 (los servidores de db dejan muy claro el destino entre esto y se quejará si tiene la verificación lógica de nulo pero obtiene y vacía la cadena). Creo que string.IsNullOrEmpty es una de las 5 peores prácticas/funciones que he visto porque de alguna manera fomenta/hace que se vea bien a las personas para iniciar sus cadenas y puede tratarse como nulo. Esta función nunca debería haber sido añadida y creo que los chicos de .Net deberían intentar eliminarla :) ¿Quién necesita y vació la cadena de todos modos? Nunca lo he usado a menos que tuviera que hacerlo debido a los proyectos existentes que lo usa

Answer 10

Al implementar la comprobación de argumentos en las API, generalmente comprobo cada condición por separado y arrojo excepciones diferentes: ArgumentNullException para una referencia nula o, dependiendo de la API especificaciones, ArgumentException para una cadena vacía. En este caso, usar String.IsNullOrEmpty no le permite distinguir entre estas dos condiciones de error por separado.

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