Métodos de extensión: IsNull e IsNotNull, ¿uso bueno o malo?

Question

Me gusta la legibilidad.

Así que, hace unos minutos, se me ocurrió una extensión mothod para la sintaxis de tipo (x =! Null), llamada IsNotNull. Inversamente, también creé un método de extensión EsNulo, por lo tanto

if(x == null) becomes if(x.IsNull()) 

y

if(x != null) becomes if(x.IsNotNull()) 

Sin embargo, me preocupa que podría estar abusando de los métodos de extensión. ¿Crees que esto es un mal uso de los métodos de Extenion?

Answer 1

no parece más fácil de leer y podría confundir a la gente que lee el código, se pregunta si hay alguna lógica que son conscientes de en esos métodos.

He utilizado un método PerformIfNotNull (método Func) (así como una sobrecarga que realiza una acción) que puedo pasar una expresión lambda rápida para reemplazar todo el bloque if, pero si no está haciendo otra cosa que no sea verificar para null parece que no proporciona nada útil.

Answer 2

Es perfectamente válido pero no creo que sea increíblemente útil. Dado que los métodos de extensión son simplemente un truco de compilación, lucho por llamar a cualquier uso de ellos "abuso" ya que de todos modos solo son pelusa. Solo me quejo de los métodos de extensión cuando perjudican la legibilidad.

Answer 3

Hay un precedente, en tanto que la clase string tiene IsNullOrEmpty

Answer 4

También está introduciendo la sobrecarga de llamada de método para algo que es una operación intrínseca de CLR. El JIT podría alinearlo, pero podría no hacerlo. Es un pequeño truco de microperforación, sin duda, pero estoy de acuerdo en que no es particularmente útil. Hago cosas como esta cuando hay una mejora significativa en la legibilidad, o si quiero algún otro comportamiento como "lanzar una ArgumentNullException y pasar el nombre arg" que es tonto hacer una y otra vez.

Answer 5

Puede tener sentido si, por ejemplo, asume que es posible que desee lanzar una excepción siempre que x sea nulo (solo hágalo en el método de extensión). Sin embargo, mi preferencia personal en este caso particular es verificar explícitamente (un objeto nulo debe ser nulo :-)).

Answer 6

No parece increíblemente útil, pero esto:

someString.IsNullOrBlank() // Tests if it is empty after Trimming, too 
someString.SafeTrim()   // Avoiding Exception if someString is null 

porque esos métodos en realidad le ahorrará el tener que hacer varias comprobaciones. pero reemplazar un solo cheque con una llamada a método me parece inútil.

Answer 7

Para seguir el patrón, debe ser una propiedad en lugar de un método (pero, por supuesto, eso no funciona con las extensiones).

Los valores de los datos en el espacio de nombres System.Data tienen una propiedad IsNull que determina si el valor contiene un valor DbNull.

La clase DataRow tiene un método IsNull, pero no determina si el DataRow es nulo, determina si uno de los campos en la fila de datos contiene un valor DbNull.

Answer 8

lugar me gustaría ir con algo como:

static class Check { 
    public static T NotNull(T instance) { 
     ... assert logic 
     return instance; 
    } 
} 

Entonces utilizar de esta manera:

Check.NotNull(x).SomeMethod(); 
y = Check.NotNull(x); 

lo personal es mucho más clara de lo que está pasando, que ser inteligente y permitir lo siguiente:

if(((Object)null).IsNull()) ... 

Answer 9

No estoy del todo de acuerdo con el razonamiento que dice "puede confundir".

Hasta cierto punto puedo ver lo que significa, que no hay ninguna razón para aventurarse fuera del "entendimiento común" - ¡todo el mundo entiende el objeto! = Nulo.

Pero en Visual Studio, tenemos herramientas maravillosas donde simplemente puede pasar el cursor sobre el método para revelar información adicional.

Si tuviéramos que decir que el método de extensión fue anotado con una buena explicación, entonces siento que el argumento de confusión se desmorona.

Los métodos .IsNotNull() y .IsNull() explican exactamente qué son. Siento que son muy razonables y útiles.

Honestamente, es una cuestión de "lo que te gusta". Si cree que los métodos lo harán más legible en el contexto de su proyecto, entonces hágalo. Si estás rompiendo la convención en tu proyecto, diría lo contrario.

He tenido las mismas ideas que usted sobre el tema y le he preguntado a varios desarrolladores muy experimentados en mi lugar de trabajo. Y ninguno de ellos ha presentado una buena razón (excepto lo que se ha mencionado sobre la "confusión" aquí) que explicaría por qué no debería hacer esto.

Vaya para él :-)