@ Dan
if otherString:
stringValue = otherString
else:
stringValue = defaultString
Este tipo de código es más largo y más expresivo, pero también más legible
Pues sí, es más largo. No estoy tan seguro de "más expresivo" y "más legible". Por lo menos, su reclamo es discutible. Incluso llegaría a decir que es francamente erróneo, por dos razones.
En primer lugar, su código enfatiza la toma de decisiones (bastante extrema). Por otro lado, el operador condicional enfatiza otra cosa, a saber, el valor (o la asignación de dicho valor). Y esto es exactamente lo que quiere el autor de este código. La toma de decisiones es más bien un subproducto del código. La parte importante aquí es la operación de asignación. Su código oculta esta tarea en un montón de ruido sintáctico: la ramificación.
Su código es menos expresivo porque cambia el énfasis de la parte importante.
Incluso entonces su código probablemente superaría algún arte ASCII oscuro como ?:
. Un en línea- if
sería preferible. Personalmente, no me gusta la variante presentada con Python 2.5 porque está al revés.Yo preferiría algo que se lee en el mismo flujo (dirección) como el operador ternario C pero usa palabras en lugar de caracteres ASCII:
C = if cond then A else B
Este gana sin esfuerzo.
C y C# lamentablemente no tienen una declaración tan expresiva. Pero (y este es el segundo argumento), el operador condicional ternario de las lenguas C está tan arraigado que se ha convertido en un modismo en sí mismo. El operador ternario es tan parte del lenguaje como la declaración "convencional" if
. Debido a que es una expresión idiomática, cualquiera que conozca el idioma inmediatamente lee este código correctamente. Además, es una forma extremadamente corta y concisa de expresar estas semánticas. De hecho, es la forma más corta imaginable. Es extremadamente expresivo porque no oscurece la esencia con ruido innecesario.
Finalmente, Jeff Atwood ha escrito la conclusión perfecta para esto: The best code is no code at all.
El segundo ejemplo/funciona /, pero vea mi comentario sobre cómo puede especificar la comparación. –
¿No es eso al revés?En general, el y/o truco está mal visto debido a errores como "cond y A o B", donde A resulta ser un valor falso como 0. Hay soluciones como (cond y [A] o [B]) [0 ], pero la sintaxis if/else se agregó prácticamente para eliminar la necesidad de tal abuso. – Brian
No es al revés. La sintaxis if/else se agregó para 'corregir' la necesidad que tenían las personas de un operador ternario que los condujera a la rotura y/o al truco. Sin embargo, observe cómo mi ejemplo no usa 'y'. Solo usa 'o', que es una forma mucho más directa de hacer lo que el OP quería. No hay gotcha allí. –