02 abril 2013

Autoexplicativo vs. comentado... Fight


Va por adelantado que esta entrada esta dedicada, como mínimo  a los que están iniciados en el mundo de la programación, así que si no es tu caso, deja de leer.

El tema del código autoexplicativo o comentado es algo que se lleva discutiendo desde que se tiro la primera linea de código, de hecho  ya creo que si dos programadores se encuentran en un ascensor, en lugar de hablar sobre el tiempo, hablan sobre esto.

Lo curioso del asunto es que después de todos estos años la discusión sigue y vaticino que seguirá toda la vida. Yo parto de la base de que el código siempre ha de ser autoexplicativo, es decir los nombres de los métodos, funciones, variables y demás objetos deben dejarte claro su uso, eso si, se ha de programar para programadores no para neófitos. Una vez que esta esto claro he de decir que los comentarios, para mi, también son obligatorios, pero como en todo hay que usar la cabeza.

Empecemos porque el JavaDoc (o similar dependiendo del lenguaje) hay que tomárselo por costumbre, aunque solo sea por limpieza, por lo que yo no lo cuento como comentario. Los comentarios hay que usarlos par aclarar algo que se salga del proceso normal, esto se va haciendo mejor con la experiencia, me explico.
En la programación, como en casi todo en esta vida, hay una serie de normas que se han ido estandarizando, oficial o extraoficialmente, y que todos acabamos usando, por lo que el nombre de la clase (volvemos al código autoexplicativo) ya nos ha de indicar que vamos a encontrar dentro, por lo que si abrimos una clase mapper no nos asustará encontrar un montón de métodos "fromTo" que sabemos se sobra como funcionan .set(.get). Vale hasta hay bien, todo perfecto, pero si nos topamos un .set(codInternational), y eso, de donde a salido, pues quizás un pequeño comentario solucione el problema, o quizás haya un if que no sea del tipo que yo llamo "empty" (no null ni vacío) o un for con una limitación "extraña", no se hay mil ejemplos.

El resumen de todo esto, en mi opinión, es que los comentarios han de ponerse siempre que algo altere la linea de ejecución estándar del tipo de método que estamos implementando siempre y cuando el código sea autoexplicativo.

No hay comentarios: