2010-11-06 26 views
5

Si no te gusta el operador condicional ternario, en primer lugar, no hay necesidad de responder;)ternario (condicional) del operador y de estilo

por lo general ven esto usa en conjunto con una expresión de asignación como:

var foo = (some_condition) ? then_code : else_code; 

Sin embargo, me gustaría utilizarlo para reemplazar código simple como:

if(some_condition) { 
    do_something_simple; 
} else { 
    do_something_else; 
} 

y en lugar de hacer:

(some_condition) ? do_something_simple : do_something_else; 

Es probable que esté haciendo esto en JavaScript. En lo anterior, devuelve indefinido, por lo que no requiere la asignación. Me gusta el espacio ahorrado, pero me pregunto qué piensa la gente sobre este tipo de uso, ya que, de nuevo, suelo ver solo ternario con una tarea.

EDIT: He visto respuestas que aluden a "intento de ocultamiento". Aunque se usa clásicamente en expresiones, ¿cómo es que esto oculta la intención más que usar en una expresión? ¿Especialmente en un lenguaje dinámico donde uno puede ver el uso de operadores ternarios en todo el lugar?

+0

Pregunta duplicada. Por favor siempre mire las preguntas previamente hechas y respondidas por Frist. Aquí está el enlace, vea si ayuda: http://stackoverflow.com/questions/3622244/full-if-else-statement-vs-conditional-operator –

+2

Consejo: Tenga en cuenta que este operador ternario en particular se suele llamar el operador condicional. Un operador "ternario" es solo un operador con 3 operandos, de ahí la palabra "ternario". No hay muchos operadores ternarios, pero en idiomas que tienen múltiples, el condicional es solo uno de ellos. –

+0

@Mazhar: esa pregunta se trata de usar '?:' De la manera normal y aceptada como una opción de nivel de expresión. Se trata del abuso de '?:' Para llevar a cabo efectos secundarios activos, para reemplazar 'if-else'. Personalmente, odio tanto esta práctica. – bobince

Respuesta

3

El operador condicional normalmente debería usarse en expresiones que producen expresiones de valor, y lo mejor es que no se use como reemplazo de la sentencia 'if/then/else'. Usado de vez en cuando, no habría ningún problema en particular; usado sistemáticamente, creo que estaría ocultando la intención del código de los lectores.

+0

por lo que no hay ninguna razón técnica por la que no se puede utilizar en ese momento. – dewd

+0

Merece la pena distinguir, también, entre (1) una expresión funcional de JavaScript, en la cual el valor clave de las expresiones condicionales es que ** redactan ** de una manera que las instrucciones condicionales no lo hacen, y (2) un estilo imperativo, en el que las expresiones no son siempre necesarias, y las declaraciones a menudo son suficientes. – houthakker

2

Ésta es mi preferencia personal:

En este caso, creo que cae en el pensamiento "código está escrito para la gente a leer, no para la máquina". Debido a que la mayoría de las personas no escribe if then else de esta manera, puede causar confusión, aumentar el tiempo para entender el código y posiblemente introducir errores: si alguien lo vio y pensó que no hay asignación a nada, debe ser "sobrante" código y vamos a eliminarlo, entonces la limpieza del código se convierte en la introducción de errores.


Citado de: Los programas deben ser escritos para que la gente lea, y sólo incidentalmente para máquinas de ejecutar.

- de "Estructura e Interpretación de Programas Informáticos" por Abelson y Sussman

Charlie Martin dijo Is Code For Computers or for People?:

Si el ordenador no lo ejecuta, se ha roto. Si las personas no pueden leerlo, se romperá. Pronto.

Y creo que sí, el código está escrito para que la máquina lo entienda (y lo ejecute correctamente), y también es importante que la gente entienda. (a menos que esté escrito intencionalmente difícil de entender para ganar honorarios de consultoría, pero pueden contratar a otra persona más tarde o para el próximo proyecto, o escrito intencionalmente difícil de entender para la seguridad laboral que si la gente no puede entender bien su código, pueden hacerlo " te despido temiendo que otras personas no puedan mantener el código ... tal vez haya 2 lados en una cosa ... cada vez vea más casos como este)

+0

Guau, si tuvieran que eliminarlo por pensar que es un "sobrante" código que parecería una IMO bastante agresiva. La cita es interesante pero supone que el uso propuesto confunde de hecho al lector del código. Sin embargo, ¿es el hecho de que hay menos líneas que lo hacen realmente más legible? No estoy seguro;) – Rob

+0

hm ... menos líneas no necesariamente lo hacen más legible. Por ejemplo, un programa de 35 líneas puede parecer más complicado que si fuera de 3 líneas, pero algunas de esas de código 1 pueden ser muy difíciles de entender. –

0

La pregunta es tonta porque estás hablando de JavaScript que permite cosas extrañas.

El operador condicional ternario, en un lenguaje de programación clásico, requiere que ambos casos sean expresiones, no declaraciones. De esta forma, puede usarlo para elegir entre dos expresiones según una condición booleana, pero no como una rama if/else normal.

en un lenguaje como JavaScript esta diferencia desaparece porque una declaración en realidad devuelve un valor para que pueda utilizar el ternario y simplemente descartar el valor indefinido devuelto por su estado de cuenta.

Desde mi punto de vista, que reside más en otro lenguaje de programación, esto puede generar confusión también si ahorra espacio, pero creo que es una cuestión de preferencia. ¡Simplemente no te acostumbres demasiado, ya que solo unos pocos lenguajes de programación permiten este tipo de uso del operador ternario!

+0

> tonto - Creo que esta es exactamente la razón por la que lo pedí. No estoy acostumbrado a verlo en idiomas más clásicos, pero sí, está permitido en JS. – Rob

0

El operador ternario es bueno para programas maduros/estables, pero no en un entorno en constante cambio. Supongamos que debe agregar un código adicional a cualquier rama; es mucho más fácil cuando tiene la sintaxis if/then/else.

+0

No creo que madurez tenga nada que ver con eso. Reafirmaría para argumentar que es bueno para condiciones muy simples. IMO – Rob

+0

Esa condición muy simple puede ser necesaria para extenderse en algún momento inesperado. – Thevs

Cuestiones relacionadas