Phi

Engineer's blog

Código limpio: mandamientos en el desarrollo de software



El desarrollo de software es una actividad apasionante para quien decide realizarla, aquí todo se resume en enfrentar desafíos bajo la lupa de la lógica, sin embargo no todo es felicidad en el camino de la creación, un arduo trabajo espera y aunque la experiencia hace del maestro un sabio, con el tiempo malas prácticas conllevan a odiar una hermosa profesión por culpa de malos “expertos”. El presente artículo los conducirá a explorar aquellos “tips” básicos que permitiran escribir a los desarrolladores un código más limpio.

Leyendo el libro Clean Code: A Handbook of Agile Software Craftsmanship de Robert Martin me causó gracia la imágen que decía que la única medida válida de calidad de código son los What The Fuck por minuto que pronuncia un desarrollador al ver dicho código. No hay nada más estresante para un programador que esforzarse para entender el código de los demás o peor aún el suyo propio. Es por esto que propongo a quienes nos dedicamos a esta profesión que sigamos los siguientes pasos como nuestros mandamientos, no olvidemos que así determinaran que tan buenos o malos hemos sido en el camino del señor.

  1. Dejaremos el código más limpio de lo que se ha encontrado: No creo que este mandamiento necesite presentación simplemente es cuestión de mejorar nuestro karma.

  2. Seremos seres de principios: Un ser humano jamás abandona sus principios, con ellos construye, así que en cada línea garantizaremos SOLID.

  3. Asignaremos nombres que revelen intenciones: Basta de asignar nombres a las variables, funciones, clases, entidades, etc., que no revelen las intenciones de por qué fueron creadas. Si éstas denotan medidas físicas, en su nombre debe estar las unidades que llevaran. Adicionalmente la no asignación de nombres es también un problema, comparar variables con números o carácteres deja mucho a la imaginación, éstos números y/o carácteres deben ser asignados a variables constantes que hablen de lo que son. En conclusión, llamemos las cosas por su nombre.

  4. No crearemos desinformación: En teoría nadie debería desinformar pero sabemos que esto no es así, la desinformación es ya un arte de engaño que doblega voluntades. Nuestra misión es la de ser concisos, no llamemos List a lo que no lo es, no usemos nombres con pequeñas variaciones, hagamos diferenciar la amabilidad del coqueteo.

  5. Realizaremos distinciones con sentido: Aunque nuestra relación con el compilador sea de marido y mujer, donde ignoramos advertencias y modificamos por petición, recordemos que escribimos para colegas. A veces una palabra de más no ayuda a diferenciar las distinciones, agregar al final info, data, the, a, an, etc., no ayuda a distinguir entre DogData y DogInfo, así que aunque la compilación sea exitosa y su programa sea funcional, recuerde que si no usa distinciones con sentido será un mal hablado.

  6. Usaremos nombres que se puedan pronunciar: Aún no comprendo por qué desarrolladores asignan nombres cual canción de rap estuviesen cantando, se requiere del uso de comentarios en el código que logre explicar si se está invocando una función o un demonio del más allá. Recuerde que es un lenguaje, se usa palabras existentes.

  7. Usaremos nombres que puedan ser buscados rapidamente: Imagine asignar al número de Euler el nombre “e” y que otro desarrollador desee buscar ésta varible en el código, si así son las cosas mejor seguir buscando la ciudad de El Dorado.

Como pudimos observar la asignación de nombres parece ser una actividad trivial dentro del ejercicio de la programación, sin embargo es necesario seguir unas pautas para una escritura correcta. Adicional es necesario tener presente que la implementación de codificaciones ha quedado en la antigüedad por lo que no es recomendado usar la notación húngara, los nombres de las clases no deben ser un verbo, los nombres de los métodos deben contener verbos, si son de acceso, modificación o predicados deben ajustarse al estándar de JavaBean, ¡uff!, las demás recomendaciones las dejaré a las capacidades investigativas del lector, mientras continuemos con los mandamientos.

  1. Implementaremos funciones de tamaño reducido: Si no queremos ser el Belfegor provocando bostezos y deseos lujuriosos hacia otras profesiones, debemos escribir procedimientos, funciones y métodos de manera reducida, tanto como sea posible. Siempre se hace una sola cosa y bien.

  2. Usaremos sangrado (indentation) limitado: El sangrado es de uso obligatorio, siendo así, cuando se habla de limitarlo, se establece un número reducido de anidaciones ya sea por condicionales o ciclos. Nada de crear escaleras al cielo.

  3. No conoceremos un tal switch: Switch es una estructura de control poco recomendada (algunos ni la toleran), pero haremos un alto y daremos una oportunidad a ella cuando solo aparezcan una vez, se use para crear objetos polimórficos y se oculte tras una relación de herencia. Todo un patito feo.

Recuerda que lo aquí dicho es solo un artículo básico de las sugerencias al momento de escribir código. A continuación registraré los últimos mandamientos que aunque sean ley dependen de ti realizar y aplicar los decretos reglamentarios.

  1. Crearemos funciones sin argumentos: Cuanto mayor sea el número de argumentos de una función más complejas serán las pruebas unitarias a realizar sobre dicha función, además aumenta la dificultad de su entendimiento. Las funciones diádicas y triadas serán aceptadas únicamente cuando exista una fuerte relación entre los datos como por ejemplo los puntos cartesianos.

  2. No usaremos comentarios: Los comentarios son la explicación de un chiste. Si tu código está bien escrito no requiere de comentarios que explique lo que éste realiza, además éstos no son actualizados por los desarrolladores y con el transcurrir del tiempo pasan de ser un mal chiste a desinformar.

  3. Pensaremos que nuestros archivos son hojas de un libro: Cada proyecto de software es un libro. Imagina leer una página de abajo hacia arriba, navegar entre capítulos para entender un párrafo, etc. La ubicación de las funciones, estructuras, variables, etc. en el archivo importa.

  4. Siempre aplicaremos la Ley de Demeter: En la programación orientada a objetos la principal diferencia entre las estructuras de datos y los objetos son la ocultación de los datos tras abstraciones. Es por ello que cada unidad no debe tener conocimiento acerca de las demás. Es cuestión de hacer lo que nos dicen nuestros padres, “No hables con extraños”.

Aunque aquí terminan los mandamientos (lo sé, debieron ser diez), faltaron por mencionar muchos más de ellos, por lo que aconsejo al lector continuar indagando y practicando. El camino hasta ahora comienza.