El término clean code se atribuye al ingeniero de software Robert Cecil Martin, que lo utilizó en su libro Clean Code: Re­fa­c­to­ri­ng, Patterns, Testing and Te­ch­ni­ques for Clean Code para referirse al código limpio. Sin embargo, sus pri­n­ci­pios son mucho más antiguos y no provienen del campo de la pro­gra­ma­ción. Te ex­pli­ca­mos en qué consiste el clean code, cuáles son sus ventajas y cómo de­sa­rro­llar­lo.

Clean code: ¿qué es?

El clean code no es un conjunto de reglas estrictas, sino una serie de pri­n­ci­pios que ayudan a producir código intuitivo y fácil de modificar. En este contexto, intuitivo significa que cualquier de­sa­rro­lla­dor pro­fe­sio­nal pueda en­te­n­de­r­lo de inmediato. Un código fá­ci­l­me­n­te adaptable tiene las si­guie­n­tes ca­ra­c­te­rí­s­ti­cas:

  • La secuencia de ejecución de todo el programa sigue una lógica y tiene una es­tru­c­tu­ra sencilla.
  • La relación entre las di­fe­re­n­tes partes del código es cla­ra­me­n­te visible.
  • La tarea o función de cada clase, función, método y variable es co­m­pre­n­si­ble a primera vista.

Un código se considera fácil de modificar cuando es flexible y ampliable, lo que también ayuda a corregir los posibles errores que pueda tener. Por todo ello, el código limpio es muy fácil de mantener y presenta las si­guie­n­tes pro­pie­da­des:

  • Las clases y los métodos son reducidos y, si es posible, tienen una sola tarea clara.
  • Las clases y los métodos son pre­de­ci­bles, funcionan como se espera y son de acceso público a través de API (in­te­r­fa­ces) bien do­cu­me­n­ta­das.
  • El código ha sido sometido a pruebas unitarias.

Las ventajas de este tipo de pro­gra­ma­ción son obvias: el clean code se vuelve in­de­pe­n­die­n­te del de­sa­rro­lla­dor que lo ha creado. En principio, cualquier pro­gra­ma­dor puede trabajar con él, lo que evita problemas como los que conlleva el código heredado. El ma­n­te­ni­mie­n­to del software también se si­m­pli­fi­ca, porque los bugs son más fáciles de buscar y corregir.

Clean code: pri­n­ci­pios generales

¿Cómo escribir código limpio? Crear clean code implica tener en cuenta ciertos pri­n­ci­pios fu­n­da­me­n­ta­les durante el de­sa­rro­llo del software. No se trata de seguir unas in­s­tru­c­cio­nes concretas que indican cómo programar en ciertas si­tua­cio­nes, sino más bien de una au­to­rre­fle­xión sobre el propio trabajo. Por este motivo, su si­g­ni­fi­ca­do despierta polémica en la comunidad de de­sa­rro­lla­do­res: lo que unos co­n­si­de­ran “limpio”, puede ser “sucio” para otros, de modo que la limpieza del código acaba siendo algo subjetivo. A co­n­ti­nua­ción, te pre­se­n­ta­mos algunos pri­n­ci­pios del código limpio muy ex­te­n­di­dos y que casi todos los de­sa­rro­lla­do­res co­n­si­de­ran útiles.

Lo más sencillo posible: KISS

KISS (del inglés keep it simple, stupid o “que sea sencillo, estúpido”) es uno de los pri­n­ci­pios del código limpio más antiguos, que ya utilizaba el ejército es­ta­dou­ni­de­n­se en la década de 1960. KISS recuerda a los de­sa­rro­lla­do­res que el código debe ser lo más sencillo posible, evitando cualquier co­m­ple­ji­dad in­ne­ce­sa­ria. En pro­gra­ma­ción, nunca hay una única manera de resolver un problema. Las tareas siempre pueden ex­pre­sar­se en di­fe­re­n­tes lenguajes y fo­r­mu­lar­se con distintos comandos. Por lo tanto, los pro­gra­ma­do­res que siguen el principio KISS siempre deben pre­gu­n­tar­se si podrían dar con una solución más simple a un problema en pa­r­ti­cu­lar.

Evitar repetir sin motivo: DRY

DRY (del inglés don’t repeat yourself, o “no te repitas”) es una co­n­cre­ción de KISS. De acuerdo con el principio DRY, cada función debe tener una re­pre­se­n­ta­ción única y, por lo tanto, ine­quí­vo­ca dentro del sistema general del clean code.

Nota

Lo contrario de DRY es WET (we enjoy typing o “nos lo pasamos bien tecleando”). El código es WET cuando contiene du­pli­ca­cio­nes in­ne­ce­sa­rias.

Con el siguiente ejemplo, verás más claro el principio DRY del clean code: su­po­n­ga­mos que el nombre de usuario y la co­n­tra­se­ña aparecen dos veces en el código para uti­li­zar­los en di­fe­re­n­tes acciones. En lugar de pro­gra­mar­los por separado, ambos procesos pueden agruparse en una sola función. De esta manera, el código WET (“húmedo”), con sus re­du­n­da­n­cias, se co­n­ve­r­ti­rá en código DRY (“seco”).

Código WET:

//Variante A
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.post(user).then(/*Variante A*/);
//Variante B
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.get(user).then(/*Variante B*/);

Código DRY:

function getUser(){
    return {
        user:getUserName();
        password:getPassword();
    }
}
//Variante A
client.post(getUser()).then(/*Variante A*/ );
//Variante B
client.get(getUser()).then(/*Variante B*/);

Eliminar lo in­ne­ce­sa­rio: YAGNI

El principio YAGNI (you aren’t gonna need it o “no lo vas a necesitar”) del clean code se basa en la siguiente idea: un de­sa­rro­lla­dor solo debe añadir funciones al código cuando sea es­tri­c­ta­me­n­te necesario. YAGNI está ín­ti­ma­me­n­te re­la­cio­na­do con los métodos del de­sa­rro­llo ágil de software. De acuerdo con este principio, en lugar de comenzar a programar partiendo de un concepto general, la ar­qui­te­c­tu­ra del software se de­sa­rro­lla paso a paso para poder reac­cio­nar a cada problema de forma dinámica. En otras palabras, se crea clean code cuando los problemas su­b­ya­ce­n­tes se resuelven de la manera más eficiente posible.

Legible antes que conciso

El código no solo debe funcionar y ser in­te­r­pre­ta­do por la máquina que lo ejecuta, sino que también debe ser co­m­pre­n­si­ble para otros de­sa­rro­lla­do­res, es­pe­cia­l­me­n­te si se trabaja en proyectos co­la­bo­ra­ti­vos. Por lo tanto, en el ámbito del de­sa­rro­llo de software, la le­gi­bi­li­dad del código siempre es más im­po­r­ta­n­te que su concisión: no tiene sentido escribir un código conciso si el resto de de­sa­rro­lla­do­res no lo entienden. Un buen ejemplo de creación de código legible sería nombrar las variables.

Los nombres de las variables siempre deben ser co­m­pre­n­si­bles. Por ejemplo, no es posible entender la siguiente variable sin una ex­pli­ca­ción o más in­fo­r­ma­ción:

int d;

Sin embargo, con el siguiente nombre, la misma variable se explica por sí sola:

int elapsedTimeinDays;
Ir al menú principal