Formas de acortar las setencias "If"

  • Autor Usuario eliminado 263618
  • Fecha de inicio
Estado

🔒 Este tema está cerrado para nuevas respuestas.

⏰ Solo el creador del tema puede solicitar la reapertura de sus propios temas, pero únicamente dentro de los 60 días previos a la última actualización.

U

Usuario eliminado 263618

Hola, aquí les dejó unas formas de acortar las sentecias "if" cortas para simplificar lineas de código, para los que inician en JavaScript.

Aunque si necesita escribir declaraciones más complicadas, definitivamente debe optar por la primera opción.

En la tercera declaración aparece un signo de interrogación y dos puntos en la línea de código, la primera condición que esta a un costado de la interrogación se ejecutará si la condición es verdadera, la condición que esta a un costado de los dos puntos se ejecutará si la condición es falsa.



1664420407374.png
 

edw9879

Gamma
Verificación en dos pasos desactivada
Verificado por Whatsapp
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Desde
12 Dic 2014
Mensajes
416
Antes usaba if, else, en mis algoritmos, hasta que conocí los operadores ternarios. Te ayudan a reducir gran parte de tu código.
También puedes usar los case, si tienes varias decisiones a elegir.
 
U

Usuario eliminado 263618

Antes usaba if, else, en mis algoritmos, hasta que conocí los operadores ternarios. Te ayudan a reducir gran parte de tu código.
También puedes usar los case, si tienes varias decisiones a elegir.
Si, yo también uso operadores terniarios para reducir las líneas de código, aunque antes me costaba comprenderlo hasta que empecé a utilizar y comprender su funcionamiento en la ejecución. 😅
 

SEMTaurus

Delta
Verificación en dos pasos activada
Verificado por Whatsapp
Desde
15 Oct 2019
Mensajes
517
No, bebé! El operador ternario solo debería usarse para asignaciones condicionales. Usarlo para sustituir el IF es un error que se paga caro después (o que lo pagará caro quien revise el código en el futuro).
Mantén tu código lo más legible que puedas, porque generalmente se escribe una sola vez, pero se lee 100 veces... A menos que seas ninja y trabajes en solitario con código desechable, entonces si, escribe taquigrafía.
 

SEMTaurus

Delta
Verificación en dos pasos activada
Verificado por Whatsapp
Desde
15 Oct 2019
Mensajes
517
Pongo otro ejemplo funesto. El tema de la asignación en cortocircuito (que usan mucho los programadores en React). Supongamos:

// inicializar todo a cero
a = b =c = 0
// obviamente ahora b = 1
b++
// ¿Qué pasará aqui?
c = a | b

Es evidente que por cortocircuito c = 1, pero eso es porque tenemos todas las piezas a la vista. Si esa última expresión hubiera estado en un lugar mucho más apartado, jurarías que c es un boolean, pero no, es un integer.
Ese tipo de estupideces quita valioso tiempo al momento de revisar código. Así que saquen su cuenta, si sale más barato escribir menos código o escribir código que se lea fácil.
 

SEMTaurus

Delta
Verificación en dos pasos activada
Verificado por Whatsapp
Desde
15 Oct 2019
Mensajes
517
Que se lo evite documentando, listo,
Es una solución. Pero el buen código debe ser AUTODOCUMENTADO, en la medida de lo posible.
¿Por qué? Porque si tienes que hacer un cambio en el código, debes cambiar tambien la documentación asociada con ese fragmento que cambiaste. ¿Ves? Buscando menos trabajo, trabajaste más. Eso no pasa si el código se explica por si mismo.
Pero repito, estas son buenas prácticas. El que quiera programar a fuerza de ninjitsus, adelante.
 
Estado

🔒 Este tema está cerrado para nuevas respuestas.

⏰ Solo el creador del tema puede solicitar la reapertura de sus propios temas, pero únicamente dentro de los 60 días previos a la última actualización.

Arriba