Mientras refactorización de código he cambiado los todos los si no las condiciones nulos a seguir la convención mayoría en mi código deCuándo utilizar!() O! = Cuando, si no nula
if (!(foo == null))
en lugar de
if (foo != null)
¿Hay alguna ventaja en cualquiera de las afirmaciones?
¿Hay alguna ventaja en cualquiera de las declaraciones en C#?
Encuentro el segundo más legible.
Aparte de eso, no hay diferencia.
Es más importante elegir una convención con su equipo y atenerse a ella en cualquier código particular.
Mucho más legible. –
Y además, cuando estás leyendo código en el primer escenario, puedes ver acciones (iguales y no), pero en el segundo es más "amigable con la lectura" y percibes como acción única. – Samich
@Oded: De acuerdo "segundo uno (* levemente *) más fácil de leer" con respecto al primero, pero es, en mi humilde opinión, demasiado ilegible a la luz de las razones y relacionadas con la sugerencia alternativa en mi respuesta de fecha 12/21/17 a continuación. Además, a menudo las "convenciones", que pueden haber estado perfectamente bien basadas en el conocimiento y las situaciones en el momento, son totalmente inadecuadas a la luz de nuevos conocimientos y/o situaciones. – Tom
Suponiendo que no tiene ==/!= sobrecargas de operador, solo usaría la segunda forma en beneficio de la simplicidad/legibilidad. Si haces han roto las sobrecargas de tal manera que hay una diferencia semántica entre los dos, a continuación, me gustaría sugerir que se fijan las sobrecargas :)
En el caso improbable de que foo == null es una indicación más clara de algo, probablemente me refactorizar que utilice una variable local:
bool somethingIsMissing = foo == null;
if (!somethingIsMissing)
{
...
}
los paréntesis alrededor de la foo == null ahora son opcionales - uso o no, según el gusto. Lo principal es que puede usar el nombre de la variable para hacer que el significado semántico sea realmente claro.
En mi humilde opinión, todavía ESTOY demasiado ilegible a la luz de las razones en y relativas a la sugerencia alternativa en mi respuesta de fecha 21/12/17 a continuación. – Tom
@Tom: creo que tendremos que estar de acuerdo para estar en desacuerdo. Prefiero usar el enfoque común e idiomático que no sorprenderá a ningún desarrollador. –
En mi opinión, no hay diferencia, el compilador optimizará el código de todos modos. Pero preferiría if(foo != null). Menos paréntesis y más fácil de leer.
normalmente if (!(foo == null)) se utiliza cuando usted tiene más variables al considerado, por ejemplo
if (!(f1 == 'a' && f2 != 'b'))
veces es simplemente más fácil de esta manera que transforman todo al contrario, especialmente cuando se utiliza operadores bit a bit.
Probablemente usaría 'if (f1! = 'A' || f2 == 'b')' para ser más claro en ese caso. –
es difícil cuando tienes una gran cadena y especialmente con banderas: -/es más "legible" como 'if (! (E.Row.RowType == DataControlRowType.DataRow && (e.Row.RowState & DataControlRowState.Edit) = = DataControlRowState.Edit)) 'no?como 'if is not a DataRow or Edit type ...' – balexandre
Ese es el tipo de situación en la que probablemente separaría la condición en una variable local con un nombre significativo. –
La primera usa dos operadores, la segunda usa una. Entonces, técnicamente, el segundo es más simple.
Mi preferido es el segundo, ya que es un poco más legible que el primero.
No hacen ninguna diferencia, así que es solo una cuestión de elección para usted.
Sin embargo, si tiene muchas otras variables en su cláusula if, la primera puede ser la que debe usar.
Su elección al final.
El único lugar donde me gustaría utilizar !(a == b) habría dentro de la aplicación del operador de != como esta manera:
public static bool operator != (MyType a, MyType b)
{
return !(a == b);
}
Puesto que, el primer formulario utiliza 2 vs 1 C# operadores, que podría compilar a más Sin embargo, en el caso de la mayoría de los casos de uso, la mayoría de los casos de uso se encontrarán, probablemente no tendrá un tamaño de código significativo o una diferencia en el rendimiento.
Lo que PUEDE hacer una gran diferencia es la legibilidad y, por lo tanto, la posibilidad de errores al escribir/modificar. Yo (y ustedes Sheldons pueden querer cubrir sus ojos ahora) evite el uso del "!" Operador com-PLETELY. "¡Grito! ¡Mi - PALABRA!" Sí, lo dije. ¡Y LO SIGNIFICO! Con una PASIÓN! Es muy fácil pasar por alto ya que a menudo está al lado de un carácter de puntuación de aspecto similar (es decir, "(") a su izquierda y una letra de identificador de aspecto similar (es decir, "I") a su derecha. Y perderlo podría tener consecuencias MAYORES ya que significaría que usted piensa que el código está haciendo LO CONTRARIO de lo que está haciendo en realidad y que los disléxicos podrían perderlo significativamente, convirtiéndolo en un problema de derechos de discapacidad protegido por la ADA.
siguiendo muy probable ejemplo:
if (!IsIisServerConnected)
if (IsOfflineMode || !(IsIisLocalServerConnected || IsIisCloudServerConnected))
yo en cambio escribiría lo siguiente:
if (false.Equals(IsIisServerConnected))
if
(
IsOfflineMode
|| false.Equals
(
IsIisLocalServerConnected
|| IsIisCloudServerConnected
)
)
o en su caso:
if (false.Equals(foo == null))
Recuerde que C (el lenguaje que C#, C++, JavaScript, Java y muchos otros idiomas actualmente populares en última instancia heredan su sintaxis básicade) fue creado en una momento en que las tarjetas perforadas seguían siendo comunes. Con CPU, RAM, monitores e IDE modernos (ese fragmento de "false.Equals (?)" Podría generarse con un atajo de teclado personalizado), para la mayoría de las personas para la mayoría de las aplicaciones, la legibilidad es mucho, mucho, MUCHO (¿mencioné? mucho "?) más importante que guardar unos pocos caracteres de código.
P.S. También podría agregar un Método de Extensión al Boolean Struct llamándolo, ¡oh, no sé, Not! ; D Para que pueda escribir:
if (IsIisServerConnected.Not())
if ((foo == null).Not())
Gracias a todos, puede refactorizar nuevamente: -/ –