A todo nivel
29 junio, 2007
  sobre los comentarios en el código
He escuchado muchas veces cómo con vehemencia y con orgullo muchos programadores aseguran no realizar comentarios a su código, esto me ha involucrado en más de una discusión poco productiva, sin embargo una vez tuvo sus efectos cuando conté la siguiente situación:
Recuerdo en la película Volver al futuro III (que protagoniza y dirige Michael J. Fox, una de mis favoritas en el género de comedias) una parte en la que Martin (el protagonista) entra a un bar en la época clásica de pistoleros del lejano oeste y traba una discusión con el pistolero malo, éste, como parte de sus burlas a Martin, hace notar a sus amigos que el chico llevaba ropa interior y él como machote sólo llevaba la que tenia puesta más las pistolas, también hace notar que Martin tenía los dientes limpios como los de una damicela, en contraste con la suya bastante ruda de hombre verdadero con restos de tabaco de mascar incluidos, claro que aparte también hizo mofa de lo "femeninamente" perfumando que estaba Martin en contraste con un macho como ellos.

No puedo evitar asociar esta escena con aquellas en las cuales los programadores dicen No realizar comentarios a sus programas, dicen ser buenos programadores tal cual el macho de la película, que nunca necesitaron ni creen necesitar de esas estúpidas cosas que se ponen entre barritas en los programas de machos.

Luego de un análisis, muchos de estos machos nunca han realizado programas mas allá que "cositas" o "jueguitos" o que nunca han trabajado en un auténtico grupo de desarrolladores para lograr un objetivo común. Es sorprendente sin embargo la vehemencia con la que defiende su posición, tal vez debido a que los únicos expectadores de su código han sido ellos mismos, equivalente a afirmar que los únicos que huelen su camisa cuando se la sacan son ellos y nadie más.

Entre una de las muchas funciones de los comentarios: pueden ser vistos como "etiquetas" que uno pone en los programas para su mejor "ubicación", tal como una secretaria pone etiquetas en los folders para ubicar maás rápidamente lo que busca o conocer el contenido de las mismas sin tener que leer cada documento que se encuentra en ellas. Esta sóla utilidad echa por tierra aquellos argumentos de los negadores de comentarios que dicen no necesitarlos por la claridad e ilumninación con la que ellos escriben el código. otra argumentación a favor es exponer el simple acuerdo o estándar del uso de variables, amén de las operaciones, de otra forma para conocerlas habría que leer todo o gran parte del código, cosas que estoy en total desacuerdo de hacerlas, especialmente si no es mi código.

Podría seguir contando muchas utilidades de los comentarios pero algunas son realmente tediosas, algunos son tan minusiosos que hay que alabar la paciencia y arte que exiben sus comentarios, ese es otro extremo que no comparto en absoluto. Los programas son programas y en estos tiempos no es posible pensar en desarrolladores superhombres que harán todo el software completamente solo. Ya no es tiempo de machotes que se enorgullesen de no necesitar desodorantes ni cepillo dental, vivimos otros tiempos, tiempos de desarrollo en equipo, tiempos de aceptar que no somos expertos en todo o en todas las áreas que quisieramos serlo, tiempos de aceptar que buenas ideas provienen también de otros desarrolladores, de aceptar los pedazos de código de otros e incluirlos en nuestros programas....tiempos ágiles.
 
Comments:
Respecto a los comentarios tengo algunas observaciones:

. La primera es que el concepto de comentario ha evolucionado con el tiempo. Cuando yo he aprendido computación, el lenguaje para expresar mis ideas era muy rudimentario: básicamente orientado a los procedimientos. Si tenías alguna forma sofisticada de solución, había que codificarla de una forma astuta. Con lo que el programa perdía la calidad de legibilidad. Entonces había que poblar el programa de comentarios que ayuden a desentrañar el objetivo del código. En algunos lenguajes viejos (que ya no me ha tocado programar sino para algún ejercicio de laboratorio) incluso los nombres de variables no podían ser lo que uno quería. Hoy en día la situación es distinta. Se puede programar en un lenguaje una solución conceptual casi directamente. Por supuesto que hay que ir refinando la solución para que sea luego eficiente, use menos recursos, etc. En resumen, el código puede ser más autodocumentado.

. No considero que el programa sea solamente el código. Hay otro tipo de lenguajes más visuales y de mayor nivel de abstracción (como UML por ejemplo) que permiten una representación más global del problema. No para razonar en los detalles, estamos de acuerdo, pero si para tener una concepción de un aspecto o global del sistema. Entonces la documentación sobre el programa también reside en estos modelos. No hay que restringirse solamente al programa.

. Finalmente, hoy en dia se promueve el trabajo en equipo. Si tienes varias personas trabajando en un sistema, y no quieres que el código dependa de una sola persona, es necesario que el grupo defina estándares de comunicación. Éstos y el sistema que el grupo defina como forma de comunicación hacen que el programa sea mucho más comprensible para un grupo de personas y no solamente para uno.

Tres motivos por los cuales la concepción sobre los comentarios debe verse desde otro punto de vista.
 
Publicar un comentario



<< Home
Un espacio para compartir ideas en el marco del desarrollo de software.

ARCHIVES
mayo 2006 / junio 2007 /


Powered by Blogger