DEV Community: Carlos Alfredo Olivera Venegas

Tips para nombrar variables en javascript y dejar de sufrir

Carlos Alfredo Olivera Venegas — Sun, 05 Apr 2020 04:39:12 +0000

Clean code, eso que hace el código legible y escalable

Esto no es "clean code" exactamente pero es un paso más para en esa dirección y te ayudará tanto a ti como a los demás developers a mantener la sanidad mental. Créeme, hasta el día más increíble y con un sol perfecto, puede tornarse gris, cuando encuentras código donde algo tan simple como nombrar las variables no es realizado correctamente, y no quizás de manera adrede por el anterior developer sino quizás por prisa o desconocimiento.

Todos estamos familiarizados con estas dos experiencias:

Felicidad, asombro y admiración por la forma tan simple e intuitiva de nombrar las variables, quizás hasta envidia de la buena de haber encontrado código tan legible que pareciera que se te dice prácticamente que hace mientras lees, casi hasta incluso te dice: Hey amigo developer, mira aquí, justo aquí va el feature que necesitas agregar.
Desesperación, frustración y la ligera sensación de que el mundo conspira en contra tuyo para que no puedas entregar ese feature a tiempo, porque ni siquiera has empezado a codear la solución sino que ya estás usando la mitad de ese tiempo para entender lo que hace el código y donde colocaras el feature necesario. Has llegado a sentir que más rápido que entender que hace esa sección de código es volverlo a hacer tu mismo desde cero.

A veces nos escudamos pensando lo siguiente:

Soy demasiado PRO por eso escribo código y a los demás les cuesta trabajo entenderlo.

Cuando en realidad el código bueno resuelve problemas complejos de manera simple, creativa y elegante.

Un ejemplo variables no semánticas sería este:

const convertObj = (x, y, z) => {
    const k = Object.keys(x);
    return k.map((key) => {
        return {
            [y]: key,
            [z]: x[key],
        }
    });
}

Es difícil de entender dándole un vistazo rápido, quizás cumple su objetivo pero no es una experiencia placentera para un developer tener que analizar cada línea de código en un proyecto.

Clean code nos dice:

Pasamos más tiempo leyendo código que creándolo, así que crear código legible para los demás y nuestro futuro yo no solo es importante sino necesario.

Sigue estos simples tips y mejorará dramáticamente tu calidad de cogido

Vamos a ver nomenclatura de acuerdo a tipo de variable. Cubriremos en este ejemplo javascript pero aplica con similitud para tu lenguaje de programación favorito.

Arrays

Antes que nada conviene pluralizar el nombre ya que los arrays son listas de valores.

/* BAD - Simplemente "fruit", eso no ni siquiera nos dice que 
tipo de variable y al ser singular no da ni luces que
es un array.*/
const fruit = ['apple', 'banana', 'cucumber'];

// OKAY - Estamos indicando al menos que la variable es un array
const fruitArr = ['apple', 'banana', 'cucumber'];

/* GOOD - simplement pluralizando ya se entiende que hablamos de
un array de valores */
const fruits = ['apple', 'banana', 'cucumber'];

// GREAT, porque "nombres" implica que cada elemento del array es un string
const fruitNames = ['apple', 'banana', 'cucumber'];

/* AMAZING - Esto ya es demasiado genial. Se entiende que es 
 un array porque está pluralizado el nombre y dentro hay objetos asociados 
 a un key donde "name" y nos dice que el valor será un string. Además una variable adicional llamada stock nos da a 
 entender que el valor será un tipo de número.
*/
const fruits = [{
    name: 'apple',
    stock: 4,
}, {
    name: 'banana',
    stock: 3,
}, {
    name: 'cucumber',
    stock: 6,
}];

Booleans

Los boolean solo pueden tener 2 valores, true o false. Dado que esto es así, podemos usar prefijos como "is", "has" o "can" que ayudará al lector inferir el tipo de variable.

/* BAD - "open" podría ser una variable de estado o function, no lo
sabemos */
const open = true;
const write = true;
const fruit = true;

/*GOOD - Ahora te preguntas, "está abierto?", SI o NO?. Es inferible
y evidente que es una variable booleana
*/
const isOpen = true;
const canWrite = true;
const hasFruit = true;

Y si como nombrar las funciones que devuelven booleanos?

const user = {
  fruits: ['apple']
}

const hasFruit = (user, fruitName) => user.fruits.includes(fruitName);

/*Si la función ya se llama "hasFruit" que nombre le pondrias a "x"? */
const x = hasFruit(user, 'apple');

Las funciones deben nombrarse usando un verbo y un sustantivo

/* Haciendo unos ajustes tendríamos esto: */
const checkHasFruit = (user, fruitName) => user.fruits.includes(fruitName);

const hasFruit = checkhasFruit(user, 'apple');

Numbers

//BAD
const pugs = 3;

/* GOOD - usando un prefijo como hacemos mas claro que es un
valor numerico */
const minFruits = 1;
const maxFruits = 5;
const totalFruits = 10;

Functions

Es recomendable usar este formato "actionResource", siempre en cuando una function realice algún tipo de acción sobre un recurso

// BAD
userData(userId)
userDataFunc(userId)
totalOfItems(items)

// GOOD - Solo agregando el verbo ya nos damos cuenta que es más legible
getUser(userId);
calculateTotal(items);

Una convención común al transformar valores es prefijar la función con el prefijo to.

// Like this
toDollars('euros', 20);
toUppercase('a string');

Finalmente usamos el singular del array durante como argumento dentro de las iteraciones.

// BAD
const newFruits = fruits.map( x => {
  return doSomething(x);
})

// GOOD
const newFruits = fruits.map( fruit => {
  return doSomething(fruit);
})

Javascript fan o lenguaje débilmente tipado? Esto es demasiado importante!

Nombrar las variables de manera adecuada es crítico porque de porque el lenguaje no te ayuda a inferir el tipo de variables.

Conclusion

Espero que estos tips te ayuden a nombrar de manera más legible tus variables, es una inversión que valoraras mucho en proyecto medianamente grandes donde hay mucho código que analizar, recuerdo que por pequeño que sea un proyecto, eventualmente crecerá y se volverá complejo, así que conviene hacer legible el código para los demás y para ti mismo para poder agregar features de forma más rápida en el futuro.

Estoy muy agradecido con el contenido original de este post de hackernoon.

Parece ilógico pero invertir un poco más tiempo no retrasar el desarrollo sino lo agiliza a largo plazo.

Suerte en tus proyectos y entre todos sigamos mejorando la calidad de cada proyecto que toquemos. Recuerda siempre dejar el código como mínimo igual o mejor de lo que lo encuentras.

Service workers con Workbox 3, tu primera vez

Carlos Alfredo Olivera Venegas — Sun, 29 Mar 2020 06:50:19 +0000

Workbox, tu primera vez

Recientemente estuve revisando documentación sobre como funciona todo este mundo increíble que nos prometen los Service Workers.
Creamos una carpetica llamada working-with-workbox y dentro la siguiente estructura. Es simple por fines didácticos, solo quiero demostrar como funciona. Posteriormente agregare mas complejidad.

1. Crear la estructura básica

 working-with-workbox
    ├── index.html (Pagina principal)
    ├── styles.css (Hoja de estilos principal)
    └── app.js (App principal)
    └── sw.js (Service worker)

Creare un archivo index.html simple importando styles.css y app.js que después serán manipulados por el service worker.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <link rel="stylesheet" href="styles.css">
</head>

<body>
  <h1>Workbox: Your first time</h1>
  <script src="./src/app.js"></script>
  <script>
    // Check if the browser support service worker
    if ("serviceWorker" in navigator) {
      //Wait untile the page has loaded
      window.addEventListener('load', () => {
        // Register the service worker
        navigator.serviceWorker.register('./sw.js')
      })
    }
  </script>
</body>

</html>

Mi archivo styles.css es super simple con fines didácticos como comentaba.

* {
  margin: 0;
}

h1 {
  font-size: 32px;
  font-weight: bold;
}

Y finalmente el archivo app.js también super simple.

console.log("Hello from the app js file");

En este punto me pregunto si siquiera vale la pena super estos pequeños archivos a gist 😅 pero bueno, sigamos.

2. Primera prueba

Para esta primera prueba vamos a levantar un servidor sencillito. Asumo que tiene python3 instalado en tu sistema operativo (En la mayoría de distros de Linux viene pre-instalado) y en macOS también.
Abre tu consola favorita y ubícate en la carpeta de tu proyecto. Y utilizaremos el comando:

python3 -m http.server 8002

Deberías tener un resultado como el siguiente:

Abrimos Google Chrome y colocamos la url que nos indica la consola (http://0.0.0.0:8002) y pulsamos ENTER.
Inspeccionando la pagina podemos ver en la pestaña "Network" que los archivos styles.css y app.js vienen directamente de la red.

Lo sabemos porque en la columna que dice Size aparece el peso de las archivos en lugar de Service Worker.

3. Agregando la magia de los service workers con Workbox 3

Llenamos el archivo sw.js con lo siguiente

importScripts('https://storage.googleapis.com/workbox-cdn/releases/5.0.0/workbox-sw.js');

const { registerRoute } = workbox.routing;
const { clientsClaim, skipWaiting } = workbox.core;
const { StaleWhileRevalidate, CacheFirst } = workbox.strategies;
const { ExpirationPlugin } = workbox.expiration;

clientsClaim();
skipWaiting();

registerRoute(
  // Cache CSS files 
  /\.css$/,
  //Use cache but update in the background
  new StaleWhileRevalidate({
    //Use a custom cache name.
    cacheName: 'css-cache',
  })
);

registerRoute(
  // Cache js files
  /\.js$/,
  new StaleWhileRevalidate({
    //Use a custom cache name for it
    cacheName: 'js-cache'
  })
)

registerRoute(
  //Cache image giles.
  /\.(?:png|jpg|jpeg|svg|gif)$/,
  //USe the cache if it's available
  new CacheFirst({
    name: 'image-cache',
    plugins: [
      new ExpirationPlugin({
        // Cache only 20 images.
        maxEntries: 20,
        // Cache for a maximum of a week
        maxAgeSeconds: 7 * 24 * 60 * 60,
      })
    ]
  })
)

Volvemos a revisar nuestra pagina en el browser y si inspeccionamos el Network nuevamente veremos que ahora los archivos css y js ya no vienen del Network sino de ServiceWorker. Asegúrate de tener marcado el checkbox “Disable cache” porque sino el browser intentara servir estos archivos desde la cache del browser y no es exactamente lo queremos. Te ha de quedar algo como esto:

Felicidades! Has implementado de manera exitosa cache para los archivos css y js. Ahora tu browser utilizara la versión que tiene guardada en la cache y estos son accesibles mucho mas rápido que pedirlos hasta el servidor, por ende tu pagina cargara mucho rápido y el usuario estará muy contento.
Hemos visto apenas la punta del iceberg. En el siguiente tutorial veremos como utilizar el Service Worker que hemos creado para tener soporte “offline” en nuestra pagina.
Aun nos falta ver muchas formas de como implementar service workers, con webpack se integra de manera distinta aunque esto esta mas orientado a aplicaciones web.

Con este sencillo ejemplo te bastaría para tu sitio personal. Estamos todos unidos para crear cada vez mejores experiencias para nuestros usuarios y la velocidad de carga de nuestras paginas y aplicaciones siempre sera una variable muy importante en esa ecuación.

Hasta la próxima!