C # String.IsNullOrEmpty: bueno o malo?

StackOverflow https://stackoverflow.com/questions/1690974

  •  18-09-2019
  •  | 
  •  

Pregunta

Después de un incidente en el trabajo en el que un mal uso 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 ( enlace ) (leer nota al final):

  

A partir del 4 de abril de 2006 hay un error   (Posible en el ECI) que hace que este   método fallar cuando optimizaciones son   encendida. Se sabe que afecta tanto   C # y VB.

Más información se puede encontrar aquí ( enlace ) . Microsoft está el error 'supuestamente' fija post-orcas, pero por desgracia mi empleador sigue utilizando VS2005. Pero si el problema se resuelve en 2008+ que así sea. Eso está bien para mí.

Mientras que la negativa de mi colega de mi código con IsNullOrEmpty para mí es ciega ignorancia (OMI), ciertamente no me puede decir por qué no para utilizar, aparte de la mala utilización de la variable de sesión. He usado IsNullOrEmpty todo nuestro código sin problemas de ningún tipo. En lo personal, me resulta mucho más fácil de leer, además de hacer las dos cosas en un comunicado.

Tras Google de opiniones sobre el tema, he encontrado sitios que llevan el pros / postura en contra. É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 (mi humilde opinión) bastante así:

  

Aquí buscamos que IsNullOrEmpty   método del tipo cadena, que   nos proporciona una buena y relativamente   método eficiente de comprobar si una   cadena es en Aceptar para guardar o utilizar. Sin embargo,   para el rendimiento, puede ser mejor   utilizar cheques nulos manuales. Las cadenas vacías   también pueden ser probados en otras formas, y   mi investigación aquí muestra que la comprobación   la longitud es más rápida.

Suponiendo que el fallo está en su lugar (y trabajando correctamente) en VS2008 / 2010 / etc., ¿Hay alguna razón no para utilizar String.IsNullOrEmpty con VS2005 y más allá? Sé que esto puede parecer un poco exagerado lo largo de un método poco tonta, pero me gustaría saber si hay algo más detrás de las escenas pasando y si alguien tiene explicaciones alternativas.

¿Fue útil?

Solución

Este problema se resolvió en .NET 2.0 SP1. No hay ninguna razón para evitar su uso ahora.

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

Otros consejos

He oído hablar de ese error antes, y por lo que he entendido que nunca se encuentra ningún código real, sólo en código como el ejemplo que en realidad no hace nada. Además, el error no es con el método IsNullOrEmpty en sí, por lo que ocurriría independientemente de cómo se comprueba la cadena.

Si el método no hace exactamente lo que quiere hacer, que debe administrarse. Sin embargo, no se debe utilizar en cada situación para comprobar si hay una cadena vacía. A veces sólo quiere comprobar si la cadena está vacía y no si es nulo.

Si la variable de cadena es nula, esto va a 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 no se supone que la variable a ser nula, es probable que desee la excepción en lugar del código tratar el valor nulo como una cadena vacía. Si algo está mal que se desea capturar lo más pronto posible, ya que será más difícil de rastrear el problema de nuevo a la fuente más larga será la excepción es de la causa.

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 sucedió

En este informe de fallo en el enlace de incluir afirma:

  

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

Desde ese es el caso no debe importar si usted está utilizando VS 2005, siempre y cuando tenga SP1 para .NET 2 instalado.

En cuanto a si es o no usarlo, echa un vistazo a este mensaje por codinghorror .

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

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

Con 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
}

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

Al igual que con cualquier lenguaje o parte del mismo, es todo acerca de conocer las ventajas / desventajas y hacer una decisión informada sobre la base de esa información. En mi humilde opinión.

En la aplicación de comprobación de argumentos de las API, por lo general de verificación para cada condición por separado y se lanzo diferentes excepciones: ArgumentNullException para una referencia nula o, dependiendo de las especificaciones API, ArgumentException para una cadena vacía. En este caso, el uso de 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");
}

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 sobre algo que debería ser relativamente fácil de solucionar.

No es necesario cambiarlo por todas partes, aunque se puede hacer reemplazar un mundial de un método estático con otra.

Me pregunto por qué la gente usa String.Empty, no es una buena cosa porque es una cadena inicializada y existe este concepto sólo en el marco .Net todas partes esto es una cadena válida con len de 0 (servidores db hacen muy clara entre este destinction y se quejará si tiene lógica para comprobar nula, pero se obtiene y cadena vacía). Creo que String.IsNullOrEmpty es uno de los 5 peores prácticas / funciones que he visto nunca, porque de alguna manera se fomenta / hace que se vea la gente ok a init sus cadenas y puede ser tratado como nulo. Esta función no debería haber sido añadido y creo que los chicos .Net deben tratar de eliminar gradualmente hacia fuera :) ¿Quién necesita y cadena vacía de todos modos? Nunca he utilizado a menos que tuviera a causa de los proyectos existentes que utilizan

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top