Evita efectos colaterales en las cláusulas if para mejorar la legibilidad del código
Los if deben usarse solo para evaluar condiciones; cualquier acción con efectos secundarios debe extraerse a una variable explícita.
En Java (y en la mayoría de los lenguajes), la única responsabilidad de una cláusula if es decidir si una condición es verdadera. Cuando se insertan llamadas a funciones con efectos colaterales dentro del propio if, el código pierde claridad y se vuelve propenso a errores de interpretación.
Un ejemplo típico es if ( enqueueMessage(message) ) { … }. Aquí el lector no sabe si enqueueMessage devuelve true cuando el mensaje se encola correctamente o cuando la cola está llena. La solución es asignar el resultado a una variable descriptiva:
boolean success = enqueueMessage(message);
if (success) {
// …
}
Esta forma se lee como "si tuvimos éxito…" y elimina la ambigüedad. Lo mismo ocurre con métodos que devuelven valores numéricos. En vez de if ( flushQueue() == 0 ) { … }, es preferible:
int itemsFlushed = flushQueue();
if (itemsFlushed == 0) {
// …
}
Separar la acción (vaciar la cola) de la comprobación (cuántos ítems se vaciaron) facilita la lectura, sobre todo cuando se revisa el código rápidamente.
Otro caso problemático es usar métodos mutables dentro del if, como if (!categorySeen.add(categoryID)) continue;. Un desarrollador que asume que un if nunca tiene efectos secundarios podría interpretar erróneamente esa línea como una simple prueba de pertenencia. Descomponerlo en dos pasos aclara la intención:
boolean isNewCategory = categorySeen.add(categoryID);
if (isNewCategory) {
// procesar la categoría
}
La combinación de efectos colaterales y evaluación de cortocircuito también genera sorpresas. if (queueNeedsFlushing() && flushQueue() == 0) { … } ejecuta flushQueue() solo cuando queueNeedsFlushing() devuelve true, pero el segundo llamado pasa desapercibido en una lectura superficial. Lo correcto es separar la lógica:
if (queueNeedsFlushing()) {
int itemsFlushed = flushQueue();
if (itemsFlushed == 0) {
// manejar caso sin elementos
}
}
En resumen, sacrificar unas cuantas líneas por claridad es una buena inversión. Un código legible reduce la carga cognitiva de quien lo mantiene y evita bugs ocultos por malas interpretaciones. Para seguir la discusión y ver ejemplos adicionales, consulta los comentarios en el hilo original.
