c# - name - ¿Cuál es la forma más clara: if(! Value) o if(flag== value)?
xml doc (18)
Entiendo que esta es una pregunta subjetiva, por lo que me disculpo si es necesario cerrarla, pero siento que surge con la frecuencia suficiente para que me pregunte si existe una preferencia general por una forma sobre la otra.
Obviamente, la mejor respuesta es "refactorizar el código para que no necesites probar la falsedad", pero a veces no hay una manera fácil de hacerlo y la rama "else" simplemente continúa el proceso. Entonces, cuando debe tener un constructo "if not false", que es el estándar preferido:
El operador no
if (!value)
O la prueba de falsa
if (value == false)
Cualquier condición que un bloque if
debe evaluar para ejecutar debe evaluar a true
.
Por lo tanto, cuando value
es false
, la razón por la cual if (!value)
permite que un bloque if
se ejecute es porque the !
el operador esencialmente invierte el valor false
del value
en true
, lo que hace que la condición resultante dentro del paréntesis se evalúe en una true
que un bloque if
necesita para ejecutarse.
if (value)
, if (!value)
, if (flag == value)
, if (value == true)
, if (value == false)
, dependiendo de lo que se quiere lograr, son códigos válidos.
Cualquiera que prefiera. Elija uno y quédese con él.
De hecho, muchas de las formas posibles.
Esta no es la forma en que está escrito en los estándares, pero así es como lo veo:
//if foo is(or exists)
if(foo)
//if foo is true
if(foo == true)
//if foo doesn’t exist
if(!foo)
if foo is false
if(foo == false)
Por lo tanto, no veo que == falso sea redundante.
Estoy a favor del estilo if (!value)
Page.IsPostback
if (!value)
al menos para evaluar variables o propiedades comunes como Page.IsPostback
y similares. Para cualquier cosa más compleja, tienden a paréntesis de la expresión de esta manera:
if (!(SomeType.SomeProperty.CallingAMethod(input).GetSomething.BooleanProperty))
Solo para llamar un poco más la atención.
Con todo, es un argumento para el estilo Perl a unless
y until
palabras clave.
Lamento decir que el segundo me parece estúpido.
Agregaría un nivel extra, si alguien lo prefiere:
if( (value==false) == true )
:)
No creo que sea tan subjetivo. Nunca lo he visto recomendado en la forma más larga. En realidad, todos los libros y guías de programación y "Cómo ser un buen programador". Los que he leído lo desaniman.
Cae en la misma categoría que
if (value) {
return true;
} else {
return false;
}
OTOH, todas las respuestas dadas aquí hacen que mi primera afirmación sea casi igual no verdadera.
Normalmente preferiría si (! Value) también, cuando sé con certeza que el valor es un booleano. Pero muchas veces puede ser una cadena o un número.
El número cero se evaluaría como falso en condicionales en muchos idiomas (aunque no todos); sin embargo, la cadena "0" se evaluaría como verdadera . Este es un problema particularmente en JavaScript, particularmente si recibe cadenas JSON del servidor, particularmente si el servidor está escrito en PHP (porque la mayoría de los desarrolladores de PHP son lo suficientemente descuidados como para tomar valores de la base de datos y llamar a json_encode, sin saber que el DB produce cadenas de caracteres y no tiene ni idea de que todos esos ceros y unos que usan como campos booleanos se codificarán como cadenas en el otro extremo, por lo que todos se tratan como verdaderos en condicionales).
Despotricar sobre. Mi sugerencia: sea explícito, especialmente si su idioma es del tipo "muy dinámico" (es decir, JavaScript, PHP, Perl).
Opinión disidente (tipo de)
Desde el punto de vista de compilación, obtendrás la misma IL, por lo que solo importa desde el punto de vista de la legibilidad.
Desde ese punto de vista, el if(value == false)
es más obvio para un lector casual, ¡y hay menos posibilidades de perderse! antes del bool.
Honestamente, utilizo ambos enfoques, y la mayoría de las veces, lo hago depender de mi nombre de variable. Si todavía suena bien decir "no" en lugar del "bang", es probable que use la notación bang
p.ej
if(!gotValue) {}
//if (I''ve) not gotValue
//but
if(checkValue == false){}
//If (I''ve) not checkValue doesn''t quite work here grammatically.
Personalmente me gusta
if ((value == false) == true)
...
porque esto es verificar que el value is false
la declaración value is false
está evaluando realmente a un booleano verdadero ...
y, entonces, obviamente, cubrir ambas posibilidades agrega aún más claridad,
if ((value == false) == true && (value == false) != false)
<grin/>
y para aquellos de ustedes que son verdaderos glotones por la claridad, y exigen legibilidad incontrovertible, sugeriría
if (((value == false) == true && (value == false) != false) == true)
Prefiero la segunda opción, el if (value == false)
uno. Con mucho gusto uso if (~value)
o if (not value)
en los idiomas que lo soportan, ¡pero eso !
simplemente se fusiona waaaaay con mucha facilidad ya sea con el nombre de la variable o llaves de apertura o | o || operadores ... al menos en mi opinión.
Además, dos cosas:
- Nunca hago
if (value == true)
, y soy consciente de que soy inconsistente. Y aunque la consistencia es muy importante en mi opinión, ¡qué molesto!
es simplemente peor. - Creo que es realmente una cuestión de gusto personal, al igual que el debate de la llave en la nueva línea. Nunca criticaría a un compañero de equipo por tonterías como esas, y me cuesta entender a las personas que lo harán.
Si la condición es solo una comprobación de un solo valor, entonces !value
es más rápido.
Sin embargo, cuando la condición contiene múltiples comprobaciones de valor, me resulta mucho más fácil leer value == false
. De alguna manera, es más fácil analizar múltiples verificaciones de igualdad que múltiples negaciones de valores.
Uso Not value
al codificar en VB, pero tiendo a usar value == false
cuando codigo en C #. Encuentro que el signo de exclamación a veces puede perderse en el nombre de la variable (por ej., Legal). Tal vez sea porque soy un veterano experimentado.
Yo preferiría usar if(!value)
porque, dependiendo de los nombres de las variables involucradas, el caso "verdadero" tiene mucho más sentido según la semántica inglesa.
Considere uno de los ejemplos en este artículo de MSDN :
if(pane.IsChecked)
se lee en inglés como, "Si el panel está marcado".
Sin embargo, if ( pane.IsChecked == true
) lee en inglés como "If si el panel está marcado como verdadero". Esa declaración es mucho menos clara en inglés de lo que debería ser.
Una de las razones por las que no escribimos código C # en binario es la legibilidad humana. Si le dan la opción entre el código que fluye bien cuando lo lee y el código que no lo hace, el lado con el que es más legible. No creo que agregar el " == true
" haga que este ejemplo sea más legible, y MSDN tampoco lo cree así.
Por supuesto, este es un ejemplo bastante pequeño del que preocuparse. Pero como han indicado algunas de las otras respuestas, no aplicar esta forma de pensar a casos de mayor escala puede perjudicar la legibilidad.
Yo uso if (value == false) The! en if (! value) es tan pequeño que a veces lo extraño.
if (!value)
es más fácil / más rápido de seguir. Subjetivo como dijiste. Mientras seas consecuente, esto es lo principal.
EDITAR
Otro punto para agregar: la omisión de las palabras clave verdadero / falso también debería (con suerte) obligar al codificador a usar variables mejor nombradas. Las variables de Bool siempre deben indicar el significado o el propósito del estado, como por ejemplo:
if (MyWallet.IsEmpty)
No hay ninguna razón con lo anterior para usar == false
o == true
ya que es redundante. Lo anterior es humano legible de inmediato.
Mucho mejor que tener que descifrar:
if (MyWallet.EmptyStatus == true)
o algo ridículo como este.
if(!value)
es más claro y más "elegante", especialmente si nombra variables booleanas correctamente
- es lo que sea
- hasWhatever
- etc
Algo como
if (Page.IsPostback == true)
me parece redundante
Nunca usaría if(value == true)
, así que por consistencia tampoco usaría if(value != false)
.
if (!value)
Esto es siempre más claro en mi opinión.
if (value == false)
Odio decir esto, porque suena algo malo, pero esto normalmente muestra que la persona que escribe el código realmente no entiende el uso de los valores booleanos. No necesita volver a validar qué es un booleano en una sentencia if. Es redundante
(Personalmente, también me enojaría con la persona si nombraran el value
la variable en lugar de algo más significativo. Tengo la sensación de que lo que publicaste es solo código psuedo, definitivamente lo cambiaría en una revisión).
Editar (en respuesta a un comentario a continuación):
Puede parecer trivial, pero a menudo es un signo de cosas mucho más grandes. A decir verdad, la mayoría de las personas que usan var == verdadero etc. no entienden. Es solo un hecho. No digo que sean estúpidos o no deberían ser programadores simplemente porque probablemente haya algo que necesiten revisar y aprender. El problema es que cuando la lógica se vuelve mucho más compleja, no entender conceptos como este puede llevar a problemas mucho más grandes en el futuro. Algunas personas dicen "es un estilo". Esta bien. La verdadera pregunta en este caso es: "¿Cómo es beneficioso para mí hacerlo de esta manera? ¿Qué es lo que yo u otras personas obtenemos de él?" Si no puede responder sólidamente a esa pregunta, entonces debe preguntarse "¿Por qué es esta una buena idea?"