¿Por qué todos los desarrolladores de Javascript deberían evitar el uso de declaraciones if?

Deje de usar declaraciones if a menos que sea absolutamente necesario.

Usar la declaración if es una forma torpe de escribir código y debe evitarse siempre que sea posible (en la mayoría de las situaciones, esto es casi el 100% del tiempo).

No me malinterpreten, if las declaraciones son útiles en ciertos escenarios y están ahí por una razón. Sin embargo, usarlos en exceso en áreas donde se pueden evitar no solo hará que su vida sea más difícil cuando llegue el momento de revisar el código dentro de unos meses, sino que también afectará el tiempo que le toma a un desarrollador comprender el contexto del código y continuar con la tarea que se les ha asignado. Esto interrumpe el "flujo" y contribuye a una menor eficiencia general. Menos es más.

Mirando el fragmento de código a continuación, estamos recuperando una tarjeta de la base de datos por número de tarjeta encriptada y devolviendo una respuesta de validación basada en ciertas condiciones.

 async validateCard(encryptedCardNumber) { const card = await this.lookupCard(encryptedCardNumber); if (!card) { console.log(NotFoundResponse.message); return NotFoundResponse; } else if (card.isBlacklisted) { console.log(BlacklistedReponse.message); return BlacklistedResponse; } else if (card.isDeleted) { console.log(DeletedResponse.message); return DeletedResponse; } else if (card.status !== CardStatus.active) { console.log(InactiveResponse.message); return InactiveResponse; } else { console.log(ValidResponse.message); return ValidResponse; } }

Tener estas muchas declaraciones if no solo requiere un poco de esfuerzo para descifrarlas, sino que a medida que se agregan más condiciones, pronto nos desplazaremos hacia arriba y hacia abajo para asegurarnos de que se hayan cumplido todos y cada uno de los casos, agregando más combustible al fuego. Junto a esto, también parece haber una duplicación de código que se puede extraer por motivos de mantenimiento.

El siguiente ejemplo hace precisamente eso. Reemplaza las innumerables declaraciones if con y (evaluación de cortocircuito), que es mucho más ordenada y fácil de entender. Para aquellos que no están familiarizados con la disyunción y la conjunción, les recomiendo buscarlo, pero aquí hay una breve descripción:

• AND lógico ( && ) evalúa los operandos de izquierda a derecha, regresando inmediatamente con el valor del primer operando que encuentra; si todos los valores son , se devuelve el valor del último operando.
• El operador lógico OR ( || ) (disyunción lógica) para un conjunto de operandos es verdadero si y solo si uno o más de sus operandos son verdaderos. Con la evaluación de cortocircuito, simplemente devuelve la primera expresión verdadera.

 async validateCard(encryptedCardNumber) { const card = await this.lookupCard(encryptedCardNumber); const response = !card && NotFoundResponse || card.isDeleted && DeletedResponse || card.isBlacklisted && BlacklistedResponse || card.status !== cardStatus.active && InvalidStatus || ValidResponse; console.log(response.message); return response; }

A medida que cambian los requisitos comerciales, también lo hace el código. En algunos casos, eso puede eliminar el código por completo, pero en otros, se está expandiendo a lo que ya está allí. Aquí hay una pregunta de entrevista popular que se hace y se refiere a su capacidad para crear una solución algo escalable.

Cree una función que convierta un número dado entre 1 y 10 en palabras

¿Simple verdad? Solo tener un montón de declaraciones if (o switch) en la función debería ser suficiente e impresionar al entrevistador.

 function convertIntegerToText(num) { if (num === 1) return "one"; if (num === 2) return "two"; if (num === 3) return "three"; // ... if (num === 10) return "ten"; }

Pero, ¿y si luego dicen esto?

Los requisitos han cambiado. Ahora queremos usar esta función para convertir números entre 1 y 100 en palabras.

¿Qué vas a hacer ahora? ¿Simplemente seguir escribiendo declaraciones if para todos y cada uno de los escenarios? ¿Qué pasa si luego cambian los requisitos para convertir números hasta 1000?

El mejor enfoque es pensar en una solución escalable desde el principio. Un principio fundamental clave a tener en cuenta al diseñar, diseñar, escribir y mantener el código es cómo el tiempo afecta la sostenibilidad del software y cómo hacer que su código sea resistente a lo largo del tiempo.

Por lo tanto, una solución escalable es un código en el que no hay declaraciones if en absoluto o unas pocas declaraciones que pueden cubrir la mayoría de los casos, si no todos, con modificaciones mínimas o ninguna requerida.

 const ONES = ["", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine"]; const TEENS = ["ten", "eleven", "twelve", "thirteen", "fourteen", "fifteen", "sixteen", "seventeen", "eighteen", "nineteen"]; const TENS = ["", "", "twenty", "thirty", "fourty", "fifty", "sixty", "seventy", "eighty", "ninety"]; function convertIntegerToText(num) { if (num < 20) return ONES[num] ?? TEENS[num - 10]; if (num < 100) return `${TENS[Math.floor(num / 10)]} ${convertIntegerToText(num % 10)}`; if (num < 1000) return `${ONES[Math.floor(num / 100)]} hundred ${convertIntegerToText(num % 100)}`; throw new Error("Number too high"); }

Para terminar, eche un vistazo al fragmento a continuación y juzgue usted mismo cuál cree que es altamente escalable, mantenible, más fácil de leer y lo ayudará a mantenerse en el estado de flujo si lo encuentra.

 // home.jsx function getCompanyTemplate(company) { if (company === "apple") { return <AppleTemplate /> } if (company === "samsung") { return <SamsungTemplate /> } if (company === "sony") { return <Sony /> } if (company === "lg") { return <Lg /> } } // OR // index.jsx export const templates = { apple: <Apple />, samsung: <Samsung />, sony: <Sony />, lg: <Lg />, } // home.jsx import { templates } from "./index" function getCompanyTemplate(company) { return templates[company]; }

Mi anterior muestra una solución de frontend escalable en profundidad sin declaraciones if . ¡Asegúrate de comprobarlo!

---

También publicado .