-
🔓 | Nombres
- Nombres descriptivos.
- Reglas permitidas y no permitidas al nombrar en JS.
- Nombres según el tipo:
- Constantes DOM.
- Variables Array.
- Variables Booleanos.
- Funciones y Clases.
-
🔒 Mini guía de estilos para JS 🚧 En construcción...
- Usar const y let (siempre).
- Comillas simples en vez de dobles.
- Espacios en blanco (siempre identa tu código).
- Usar siempre el modo estricto.
- Usar funciones como expresión.
-
🔒 Mejorando la Legibilidad con ES6+ 🚧 En construcción...
- Desestructuración (destructuring).
- Operador ternario/condicional (Conditional (ternary) operator).
- Encadenamiento opcional (Optional chaining).
- Operador de Fusión Nula (Nullish Coalescing).
Hacer cambios en un código “con mal olor” es realmente desafiante y 💔cardíaco. Lo es aún más cuando se trata de código de terceros, pero el verdadero golpe llega cuando descubres que ese código que tú escribiste hace solo una 📅semana, que en su momento parecía claro, ahora es un caos😱.
Esto sucede porque a menudo nos concentramos en que el código funcione ⚡rápidamente y resuelva el problema de inmediato. No obstante, también influyen factores como:
⏰ Tiempos de entrega ajustados: La prisa a menudo lleva a priorizar la velocidad en lugar de la calidad. ¿Quién no ha sucumbido a la presión del “🫵tienes que entregarlo ya”?
📚 Falta de experiencia en código limpio: No todos los desarrolladores, incluso con experiencia, conocen o aplican buenas prácticas. A veces, el conocimiento sobre código limpio es un lujo que pocos se permiten.
🏋️♂️ Sobrecarga de trabajo: La acumulación de tareas impulsa soluciones rápidas y poco limpias. ¿Quién tiene tiempo para lo perfecto?
💸 “Luego lo refactorizamos”: La deuda técnica se acumula como un mal hábito y rara vez se enfrenta después.
🔍 Subestimar el código limpio: Creer que “con que funcione basta” ignora que el código desorganizado es mucho más difícil de mantener y corregir a futuro.
En lugar de avanzar y hacer mejoras🚀, te ves obligado a detenerte y luchar para comprender lo que está frente a ti, intentando descifrar lo que alguien más dejó atrás. Es una experiencia frustrante que drena tu ⌛ tiempo y ⚡ energía, robándote la satisfacción de la creación.
Javascript sin olores
Cuando hablo de "JavaScript sin olores", no estoy diciendo que tu código deba oler a ☕café recién hecho, pero sí que al menos no debería asustar a cualquiera que lo mire y lea👀. En este artículo, vamos a trabajar con JS Vanilla el único lenguaje de lado del cliente y el más incomprendido. Pero con un giro de trama: aprovecharemos todas las bondades, y características modernas de ES6+ junto a convenciones, guías de estilos, patrones, en resumidas cuentas, código limpio ✨.
Y recuerda, lo que he compartido aquí son solo recomendaciones💡; no pretendo imponerte nada. Toma lo que mejor se adapte a ti o a tu equipo 🤝 y hazlo tuyo✨.
Sin más vueltas, a lo que venimos.
🚀 Nombres (Naming)
Nombres descriptivos
Esto significa que los nombres de las variables deben reflejar claramente el tipo de información que almacenan. Evita nombres genéricos o acrónimos difíciles de entender, un buen nombre de variable proporciona suficiente contexto para entender su propósito y contenido.
// Mal ❌
let cic = 5;
let p = 1051;
let d = 50;
Como puedes ver, el propósito de cada variable es un misterio digno de Sherlock Holmes🕵️♂️. ¿Por qué? Porque para descifrar qué hacen, necesitarías un montón de contexto extra, como comentarios que no existen, horas 🔍 revisando dónde demonios se usan, o tener al programador a mano, como si fuera tu propio servicio de soporte técnico.
// Bien ✅
let cartItemCount = 5;
let cartTotalPrice = 1051;
let appliedDiscount = 0.50;
En este caso, las variables reflejan claramente su contenido y propósito:
- cartItemCount: Número de productos en el carrito de compras.
- cartTotalPrice: Precio total de todos los productos en el carrito.
- appliedDiscount: Monto del descuento aplicado al carrito.
Reglas permitidas y no permitidas al nombrar en JS
-
Reglas que generan un ❌error:
- No pueden incluir espacios en blanco.
- No pueden ser palabras reservadas.
- No pueden comenzar con números, aunque sí incluirlos después de la prierma letra.
- No pueden contener signos de puntuación, con la excepción de los signos $ y _.
- No pueden contener operadores aritméticos ni otros símbolos alfanuméricos
-
Reglas que no caunsan ningun tipo de error, sino, las sigues:
- Usa lowerCamelCase ✅.
- Usa nombres en ingles ✅.
- Usar lowerCamelCase
Cartitemcount = 10; // ❌
cartItemCount = 10; // ✅ Bien
- Evitar el uso de números.
let 2cartItemCount = 6; // ❌ Mal, genera error
let cartItemCount2 = 6; // ❌ Mal, no genera error, pero evitar números.
- Evitar usar palabras reservadas del lenguaje.
Como function, class, var, const, if, while, etc.
let function; // ❌ Mal
let class; // ❌ Mal
- Evitar uso de acentos y la letra Ñ.
let año = 2024; // ❌ Mal
let ano = 2024; // ✅ Bien, aunque puede ser confuso.
let year = 2024; // ✅ Mejor, más claro y en inglés.
- Evitar uso de signos de puntuación
let !cartItemCount; // ❌ Mal, generan error.
let ?cartItemCount // ❌ Mal, generan error.
- Evitar usar espacios.
let cart item count; // ❌ Mal, genera error.
- Evitar usar guiones bajos y normales.
Nota: La única excepción a la regla, de usar guiones bajos, es al nombrar constantes.
let cart-item-count; // ❌ Mal, genera error.
let cart_item_count; // ❌ Mal, no genera error, pero evitar.
- Usar mayúsculas con guiones bajos para constantes.
const API_BASE_URL = 'https://api.myecommerce.com/v1'; // ✅ Bien
const PROMO_DISCOUNT_RATE = 0.10; // ✅ Bien
Constantes DOM
Lo sé, te estarás preguntando: ¿por qué "constantes DOM" y no "variables y constantes DOM"? La razón es que, cuando almacenamos o hacemos referencia a un elemento del DOM, lo que realmente solemos modificar son sus propiedades o su textContent, pero rara vez la referencia en sí. Por eso preferimos usar const en lugar de let. Pero, ojo, esto es solo una convención, no una regla estricta. Si en algún momento necesitas usar let, no pasa nada, usa lo que mejor se ajuste a tus necesidades.
Otra recomendación es añadir el prefijo "El" al final del nombre de la variable para indicar que almacena un elemento del DOM. Esta convención facilita reconocer de un vistazo que la variable representa un nodo DOM.
const addToCartButtonEl = document.getElementById('add-cart');
const productListEl = document.getElementById('product-list');
const toggleMenuButtonEl = document.getElementById('toggle-menu');
En otros rincones de todo internet talvez te topes con la sig. alternativa, usar el prefijo "$" al inicio del nombre de la variable, similar a cómo se hace en jQuery. Este prefijo también indica que la variable hace referencia a un objeto del DOM.
const $article = document.createElement('ARTICLE')
Ambas convenciones son válidas, pero elige una que se ajuste mejor a tu estilo de codificación o al estándar de tu equipo para mantener la consistencia en tu código.
Variables Array
Cuando guardes listas de cosas, usa nombres en plural.
let cartItems = [ // ✅ Bien
{ id: 1, name: 'Laptop', quantity: 1, price: 999.99 },
{ id: 2, name: 'Mouse', quantity: 2, price: 25.99 }
];
let categories = ['Electronics', 'Home Appliances', 'Books']; // ✅ Bien
Variables Booleanos
Imagina una caja llena de switches y ninguno dice si está encendido o apagado🔌. Darle prefijos como is, has, o can a tus variables booleanas es como etiquetar esos switches: isActive, hasPermission, canFly. ¡Sabes lo que hace cada uno al instante! ⚡️. Te ayudan a identificar rápidamente que se trata un valor booleano.
Por ejemplo, si necesitas una variable para verificar si se puede aplicar un descuento a un producto, un buen nombre sería canApplyDiscount.
let pendingOrders = true; // ❌ Mal
let hasPendingOrders = true; // ✅ Bien
let userAdmin = true; // ❌ Mal
let isUserAdmin = true; // ✅ Bien
let applyDiscount = true; // ❌ Mal
let canApplyDiscount = true; // ✅ Bien
Evita las negaciones
En lugar de nombrar una variable como isNotUserAdmin, utilice isUserAdmin. Siempre debes abordar la convención de nombres desde el lado positivo.
Veámoslo más claro en el sig. ejemplo. Entre estos nombres, ¿cuál te resulta más cómodo: isVisible o isInvisible?
!isVisible // ✅ Bien, simple, evitamos la carga cognitiva.
!isInvisible // ❌ Mal, innecesariamente complejo.
A continuación más ejemplos.
Bien ✅ | Mal ❌ |
---|---|
isOpen | isClosed |
isVisible | isInvisible, isHidden, isShowing, show, hide |
isResolved | isRejected |
isRight, isGood | isWrong, isLeft, isBad |
hasValue | isEmpty |
isDefined | isUndefined |
isOwner | isOwning, own, wasOwner, willBeOwner |
Funciones y Clases
Los nombres de funciones de JavaScript también distinguen entre mayúsculas y minúsculas. Por lo tanto, al igual que con las variables, utiliza la convención CamelCase para nombres de funciones.
Además de eso, debes usar sustantivos y verbos descriptivos como prefijos. Por ejemplo, si declaramos una función para recuperar un nombre, el nombre de la función debe ser getName.
Usar PascalCase para clases y funciones constructoras.
class Product {} // ✅ Bien
function ShoppingCart() {} // ✅ Bien
Usar camelCase para funciones nombradas.
function validateOrder() {} // ✅ Bien
🚧 En construcción... 🚧🚧
Top comments (0)