Deje de usar declaraciones if a menos que sea absolutamente necesario.  Usar la declaración   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). if  No me malinterpreten,   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. if  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   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. if  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: Logical AND Logical_OR    (   ) 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. AND lógico && falso verdaderos  El operador   (   ) (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. lógico OR ||   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   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. if   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   . ¡Asegúrate de comprobarlo! artículo if  También publicado   . aquí

Flow

Alongside

Apple

BUNCH

Mozilla

Samsung

Sony

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Programming

2022 - HackerNoon Contributor of the Year - Website Development

2022 - Software Developer of the Year

Coding Guru of 2022

Find me on my website!

Nominated for Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Coding Skills

Nominated for 2022 - HackerNoon Contributor of the Year - Programming

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - HackerNoon Contributor of the Year - Website Development

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - Software Developer of the Year

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

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

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps