Ya adelanté hace algunos meses, que la mejor forma de aprender bien a programar es sabiendo que es lo que no se debe hacer.

Hoy inaguro la primera entrega, de lo que serán varios artículos comentando código que encuentro, y que me parece un mal ejemplo en algún sentido

El código, al ir detrás de la funcionalidad, es algo en lo que el cliente no se fija, y suele ser un aspecto descuidado por los programadores.

Una aplicación puede funcionar a las mil maravillas estando mal escrita, y no dará mayores problemas hasta que tenga que ser modificada, ya sea para añadir nuevas funcionalidades, mejorar procesos, o para corregir algún problema que se ha encontrado. Más aún si la persona/equipo que se va a encargar de esta modificación, no es el mismo que creó la versión inicial del programa; o ha transcurrido ya algún tiempo desde que se escribiera por primera vez.

El código que os pongo de ejemplo, personalmente me cuesta de seguir.

La primera causa de ello, es la excesiva mezcla entre el código en si (PHP), y la presentación (HTML).

No se trata de abusar del modelo (MVC), y llevar las tres capas al extremo, pero si de encapsularlo y separarlo cuando sea conveniente.

A la dificultad en la legibilidad, contibuye también la indentación poco coherente.

En efecto, esta desestructuración del código, se debe habitualmente a modificaciones de última hora o plazos de entrega restringidos. Contra esto es difícil luchar, y solamente sería aplicable una reordenación, una reestructuración, o una refactorización a posteriori.

Otras veces, el problema viene dado por un excesivo Copiar y Pegar, y por tanto el embrollo sería evitable con un poco de método. Ya sea a la hora de escribir el código, o de evitar tanto copia y pega estructurando la aplicación de una forma más hábil.