Introduccion a Clean Code

Introducción a Clean Code (I) - Las normas

Publicado el: 07 de Octubre 2017 por Victor de Andrés Archivado en: Fundamentos | Buenas Practicas
clean code

Todos, o por lo menos la gran mayoría, queremos ser mejores profesionales, y queremos hacer las cosas mejor. El desarrollo del software es un área que avanza muy deprisa. Cada vez con más herramientas y nuevas tecnologías, pero independientemente de las herramientas que utilicemos o el lenguaje o lenguajes que utilizamos siempre tenemos una parte que subyace, el escribir código.

En este artículo y en un próximo artículo haré una breve introducción sobre qué es y cual son los principios y normas del Clean Code. Las cuales puedes poner en práctica con cualquier lenguaje de programación. Aunque lo que te recomiendo es que leas el libro "Clean Code: A Handbook of Agile Software Craftsmanship" de Robert C. Martin.

Tal y como te he comentado antes debido a la extensión de este tema voy a dividir este artículo en dos partes. En esta primera veremos las normas. Y en el siguiente los principios de Clean Code.

Los nombres.

Vamos a comenzar por la parte más sencilla. Los nombres. Que regla seguir para poner nombre a las variables, funciones, objetos o métodos. Algo que parece muy sencillo pero seguro que si lleváis algún tiempo programando os habréis encontrado nombres de todo tipo. Como por ejemplos nombres de variables como el siguiente ‘sprped’. Seguro que no os dice nada sin un entorno y en ocasiones ni con un entorno sabriais hallar su significado.

Los nombres tienen que tener un significado, cuando los leas tienes que saber inmediatamente a que se refieren. Cuando creó un nuevo nombre me hago la siguientes preguntas. ¿Que hace? y ¿Cual es su propósito?. La respuesta a estas dos preguntas es el nombre que asignare.

Los nombres tienen que estar bien diferenciados unos de otros. Evita los nombres muy similares unos a otros porque te pueden llevar a confusión posteriormente.

Los nombres deben ser pronunciables. Piensa que cuando estés hablando con un compañero de trabajo o cualquier otra persona tiene que comprenderte.

Evita los prefijos y los sufijo en los nombres. Si has cumplido las premisas anteriores nunca utilizaras prefijos o sufijos en tus nombres.

Los nombres de las clases deben ser siempre sustantivos y los nombres los métodos deben ser verbos.

Las funciones.

Las funciones es una de las partes que más utilizamos en cualquier lenguaje de programación. La longitud de las funciones no debería exceder de las 50 líneas aunque lo ideal es que sean de 20 líneas.

Una función debe hacer sólo una tarea correctamente.

Para que las funciones no superen este límite, una función nunca debe mezclar operaciones de alto nivel, por ejemplo calcular el iva de un producto en una factura, con funciones de bajo nivel, como por ejemplo realizar tareas aritméticas. Si aún así nuestra función supera este número de líneas deberíamos realizar las siguientes acciones:

  • Extract method

  • Move method

  • Descompose Conditional

Una ejemplo de una función que calcula la tarifa de una línea, con su posible descuento y verificar su disponibilidad en el almacena y si se encuentra descatalogada aplicar un descuento del 15% importe resultante sería algo similar a la siguiente:

      
  function calculaImporteBrutoLinea(__numProducto) {

    const importeDescuentoDescatalogado = 15;
    let importeBrutoLinea = tarifaCatalogoProducto(__numProducto);

    if ( productoDisponible(__numProducto) ) {
      if ( productoDescatalogado(__numProducto) ) {
        importeBrutoLinea = aplicaDescuentoEspecial(importeBrutoLinea, importeDescuentoDescatalogado);
      } else {
        if ( productoTieneDescuento(__numProducto) ) {
          importeBrutoLinea = aplicaDescuento(__numProducto);
        }
      }
    } else {
      importeBruto = 0;
    }

    return importeBrutoLinea;

  }        
      
    

Una función nunca debe recibir más de dos parámetros, en cualquier otro caso los deberíamos unir agrupadas por similitud en un objeto. Si al hacer esta agrupación tenemos varios objetos en entrada es un señal para poder dividir esa función que estamos desarrollando en varias funciones más sencillas.

Una función únicamente debe realizar una tarea y esta tarea tiene que quedar claramente definida en la función. Si una función hace varias tareas a la vez es una función mal escrita.

Comentarios

"Un comentario es un síntoma de no haber conseguido escribir un código claro". Robert C. Martin

El código que escribes debe ser autoexplicativo. Volvemos al ejemplo anterior, como puedes observar aunque no supieras de programación podrías entender que hace esta función.

        
    function calculaImporteBrutoLinea(__numProducto) {
  
      const importeDescuentoDescatalogado = 15;
      let importeBrutoLinea = tarifaCatalogoProducto(__numProducto);
  
      if ( productoDisponible(__numProducto) ) {
        if ( productoDescatalogado(__numProducto) ) {
          importeBrutoLinea = aplicaDescuentoEspecial(importeBrutoLinea, importeDescuentoDescatalogado);
        } else {
          if ( productoTieneDescuento(__numProducto) ) {
            importeBrutoLinea = aplicaDescuento(__numProducto);
          }
        }
      } else {
        importeBruto = 0;
      }
  
      return importeBrutoLinea;
  
    }        
        
      

Si cuando estás escribiendo tu código necesitas un tiempo para escribir un comentario porque no utilizas ese tiempo para refactorizar tu código de tal forma que sea autoexplicativo.

Además los comentarios tienen otro problema añadido. Cuando haces una modificación al código ya comentado normalmente no modificas también el código por lo que en ocasiones el comentario está desincronizado con el código.

Aunque por supuesto hay situaciones en las que es recomendable escribir comentarios

Formato.

Cuando estás leyendo, lees de izquierda a derecha, y de arriba a abajo. Tu código deberá seguir esa estructura porque esto afecta a la legibilidad de tu código.

Cuando utilices tanto separaciones horizontales como verticales debes realizarlas para agrupar el código en bloques o secciones.

Para esta sección no hay reglas predefinidas, puedes utilizar las que desees. Pero es importante que todos los miembros del equipo utilicen las mismas.

Algunas de las reglas que puedes definir son las siguientes:

  • Densidad vertical. Tienes que definir cuando y porque puedes dejar una línea en blanco dentro de tu código

  • Ubicación de los componentes. Normalmente en una clase lo primero que defines son las variables. Pero a continuación debes definir si escribes los métodos públicos primero y posteriormente las funciones privadas o viceversa.

Hasta aquí la primera parte de este artículo donde he expuesto las normas de clean code. En un próximo artículo veremos los principios.

Comentarios
Escribe tu comentario