Código “flecha” y cláusulas de guardia

Hace poco me encargaron cambiar un código bastante viejo para que pudiéramos usarlo en una capa de Batch donde se requiere dividir bastante lo que se quiere hacer i.e. hacerlo en lo que Spring Batch llama Tasklets.

Obviamente llego el momento en que tuve que seguir el código para entender que es lo que hacía (además de preguntar qué es lo que se supone que debe hacer, cosa diferente) y mi sorpresa fue que me topé con un código que se veía similar a esto...

Como pueden observar, todo este código es un ejemplo de lo que popularmente se conoce como arrow code o código flecha i.e. la forma del código se asemeja a una punta de flecha debido a la cantidad de if’s anidados.

Quiero puntualizar en que este tipo de código hace el programar algo bastante propenso a errores y no se diga sobre la legibilidad; en mi caso particular se usaron pocos métodos, así que el método del que hablo tenía aproximadamente 200 líneas de código y muchos más if’s de los que podía contar.

Una buena forma de refactorizar este código para hacerlo más legible es usando cláusulas de guardia (Guard Clauses). Esto consiste en hacer verificaciones a parámetros dentro del código que eviten que el código continúe si la verificación falla. Con esto no solo haces que tu diseño sea fail-fast sino que también lo haces mucho más facil de entender.

En el código anterior puedes ver algo similar a esto:
 
Que puede manejarse asi:
 
Lo cual es más legible y evita que el código subsecuente se llene de código defensivo. Si han usado librerías como Guava han visto algo similar en la clase Preconditions e.g.
 
Y con esto también haces que tus condiciones sean positivas e.g. en lugar de siempre usar una negación asi   simplemente pones la condición en forma positiva (lo cual muchos pensamos que ayuda a leer el código mas rapido).

Ahora, supongamos que queremos que nuestro framework de inyección de dependencias (en este caso Spring) inyecte ciertos objetos y además queremos asegurarnos que esos objetos no sean nulos por algún error de dedo; para hacer que nuestra aplicación falle al momento de cargar nuestro contexto y no mucho después (¡me ha pasado!). En este caso usaríamos algo similar a esto:
 
Claro, yo siempre opto por hacer un static import y esto quedaria asi:
 
Aquí la ventaja de Guava es que es fácil saber qué tipo de excepción va a lanzar el código. En   se puede discernir que lanzara un   y en   se puede entender que lanzara un  .

Para finalizar quiero hacer notar que a muchos programadores les disgusta el tener tanto codigo defensivo en sus métodos. He visto el caso en que algunos prefieren mover todos esos “checks” en un método aparte; al inicio del método principal. Esto no se me hace malo pero procuro dejarlos en el método donde se realizaran los calculos para saber inmediatamente que son y que no son argumentos válidos. Eso lo dejo a discusión de ustedes.