Este breve tutorial de refactoring explica cómo escribir cláusulas de guarda (guard clauses en inglés) en tus instrucciones if, en lugar de anidar condiciones if … else. Es una de las formas más rápidas de conseguir un código limpio y fácil de leer. El ejemplo está en JavaScript, pero el mismo estilo se aplica a cualquier lenguaje: PHP, Java y los demás.
¿Qué es una guard clause?
El patrón guard clause no es más que una técnica para hacer comprobaciones rápidas dentro de un método, por ejemplo en un constructor. Cuando un método (o una instancia de objeto) necesita ciertos valores para funcionar bien, y la aplicación nunca debería llamar a ese código con datos no válidos, la guard clause lanza una excepción en cuanto un valor no cumple una de las condiciones sucesivas. Entre otras cosas, la técnica evita ir anidando bloques if else a lo largo de la ejecución de un método.
Ejemplo en JavaScript de la técnica guard clause
Imagina que tienes que escribir un método que da formato a una fecha según su valor: puede ser un timestamp, un objeto Date o una cadena de texto, y cualquier otra cosa es un error. La tentación es escribir una cadena de if / else if / else if / else anidados.
Sin guard clauses
function getDate(date) {
let result;
if (!isEmpty(date)) {
if (isTimestamp(date)) {
result = formatWithTimestamp(date);
else if (isDateObject(date))
result = formatWithObject(date);
else if (isString(date))
result = formatWithString(date);
else
throw new DateFormatException(date);
}
return result;
}
return emptyDateError();
}
Con guard clauses
function formatDate(date) {
if (isEmpty($date)) return emptyDateError();
if (isTimestamp(date)) return formatWithTimestamp(date);
if (isDateObject(date)) return formatWithObject(date);
if (isString(date)) return formatWithString(date);
throw new DateFormatException(date);
}La diferencia se ve enseguida: con guard clauses el código es mucho más legible, y más fácil de mantener para ti y para tus compañeros.
Conclusión
Las cláusulas de guarda y las validaciones hacen lo mismo: validar la entrada. La diferencia está en si esa entrada no válida se espera y forma parte de la aplicación, o si es realmente inesperada. Usa las excepciones solo para los casos inesperados y deja la lógica de validación normal para los problemas que ya sabes que pueden traer los datos de entrada.
