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.
Top comments (1)
10/10