Clean Code

Clean Code: a Handbook guide of Agile Software de Rober C. Martin (conocido como Uncle Bob y coautor del Manifiesto Ágil) o como yo lo llamo: La biblia del programador, es un libro que debería debería estar en el temario de cualquier carrera de programación y sobre el que te deberían preguntar en las entrevistas de trabajo «Cuando fue la última vez que leíste Clean Code, y como lo aplicas?».

Es un libro que recomiendo encarecidamente a toda la gente que está empezando; si llevas un tiempo en esto y no lo conocías ya estás tardando. Para mi Clean Code se ha convertido en sinónimo de programación en condiciones: buenas prácticas, legibilidad de código,…

Realmente no cuenta nada revolucionario, todo lo que puedes leer en este libro te hará pensar «… pues claro», pero es justo eso lo que lo hace tan grandioso, más que enseñarte nada, te recuerda todo lo que has olvidado o no aplicas porque «no tienes tiempo», y te da motivos para aplicarlo de nuevo.

Making your code readable is as important as making it executable .

Escribimos código para que lo interpreten las máquinas, pero olvidamos que lo mantienen las personas. De poco sirve escribir código super eficiente y a prueba de errores si el próximo que le vaya a meter mano tiene que reescribirlo entero porque no entiende nada o le cuesta una mañana encontrar el punto donde añadir una nueva funcionalidad. Es una situación con la que me he encontrado demasiado a menudo, sobretodo en ABAP, y conozco como acaba: añadiendo un trozo de código al final de la ejecución, aportando tu granito de arena para hacer aún más grande el monstruo, y que se lo coma el que venga detrás.

Un método/perform/función con 200 lineas. Un archivo con 5000 líneas. Todo el programa en un mismo archivo. ¿Tanto nos gusta darle a la rueda del ratón?

Variable con nombres crípticos: si ya de por si es difícil memorizar a que narices se refieren campos como BUKRS, WAERS o STCD1, nos hacemos un flaco favor llamando a las variables gw_tabla1, lv_aux o peor aún i.
La longitud máxima para nombrar algo en ABAP son 30 caracteres, creo que da para poner un texto más legible. No me vale la escusa de que con nombres más largos es más fácil equivocarse, o que es más lento escribir, es justo para lo que sirve el autocompletado.

Lo mismo ocurre con los performs, ¿por qué hacemos esto?

PERFORM calcular1.
PERFORM calcular2.
PERFORM calcular3.

¿O esto?

PERFORM sumar.

Hay varias respuestas ante este dilema: no importa, yo se lo que hace, si lees el código se entiende, así lo he hecho siempre y funciona,…

You should name a variable using the same care with which you name a first-born child.

Pero la que más claro deja que estamos ante un «mal olor» que hay que corregir es: es que hace tantas cosas que no se que nombre ponerle…
Bloques de código que hacen mil cosas: consultan la base de datos con un select, loopean el resultado, lo modifican según los datos de otra tabla, calculan un sumatorio, y dependiendo de un valor de la pantalla de selección generan un excel o llaman a un ALV.
¡Si un código hace muchas cosas, sepáralo en trozos más pequeños! ¡Y dale un nombre que facilite entender lo que hace, coñe!

Hardcode: Cada vez que haces esto, un inocente gatito sufre:

IF wa-regio NE 'CANARIAS' ...

lv_waers = 'EUR'.

Me atrevería a decir que incluso IF(sy-subrc EQ 0) y lv_value = ‘X’ no son buenas prácticas, pero es una guerra en la que no quiero entrar y está tan extendido… Además tampoco hay buenas alternativas, aunque si alguien me pide consejo le diría que usara IS INITIAL/IS NOT INITIAL en vez 🙂

De todo esto y mucho más trata el libro, lo ire desgranando poco a poco en varios posts y aplicando los casos, ejemplos y soluciones que propone a mundo SAP (y de paso me lo volveré a leer) tanto en ABAP como en javascript.

Considero que todos ganaríamos mucho escribiendo un código más legible, no solo en favor de nuestros compañeros que van a tener que atacar nuestro código, también en nuestro propio favor. Promoviendo estas buenas prácticas heredaremos programas más fácilmente modificables, ademas piensa que ese programador que herede tu código puedes ser tu mismo dentro de 6 meses y te puedes acordar mucho de tu propia madre, tu veras si quieres que sea para bien o para mal.

Recordemos esa grandiosa frase que deberíamos tener siempre en cuenta al abrir nuestro IDE:

«Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live».

No he encontrado el autor original y en la versión que conocía en español hacía alusión a un maníaco depresivo con un hacha, pero creo que queda bastante clara la idea.

El libro se divide en tres partes, la primera describe los principios, patrones y prácticas para escribir «clean code», la segunda consiste en una serie de casos de estudio con bloques código a los que aplicar lo aprendido para transformar en algo más limpio y en la última explica las acciones que se tomaron para limpiar el código de los casos de estudio y el motivo por el que se tomaron.

Hay 2 puntos de la introducción del libro que quiero comentar antes de dar por concluido este artículo/post/cosa.

La primera, es la que muestra como mejor manera de comprobar la calidad de un código. Un libro que empieza así no puede ser malo.

libr

La segunda es una enseñanza a tener en cuenta al leer este libro, bueno y al aprender sobre cualquier tema:

Learning to write clean code is hard work. It requires more than just the knowledge of
principles and patterns. You must sweat over it. You must practice it yourself, and watch
yourself fail. You must watch others practice it and fail. You must see them stumble and
retrace their steps. You must see them agonize over decisions and see the price they pay for
making those decisions the wrong way.

Nota: Para los legos en el idioma de Shakespeare, el libro ha sido traducido al español como «Código limpio» pero solo lo he leído en ingles, así que no puedo recomendarlo.