Diego Gomez Deck escribió: > Hola Gallego, > >> Guillermo Schwarz escribió: >>> Bueno, XP nació de conocidos Smalltalkers, y ellos manifiestan que no es >>> necesario comentar los métodos (si al final nadie lo lee), >> Ok, si nadie lo lee quiere decir algo peor aún, están usando cosas sin >> prestar atención. En Smalltalk hay que leer mucho, mucho más de lo que >> se escribe > > Nadie habla si se lee o no, sino de si leemos comentarios o leemos > código funcionando.
Particularmente me oriento por ambas cosas, si el selector es intention revealing como decian suelo no leer el comentario*, pero si no lo es (y esto es subjetivo ya que puede o no serlo para uno u para otro) tambien leo el comentario, ya que seguramente encuentre más información ahi, ademas de ayudarme en detectar si es que puede haber algún problema en la implementación, por ejemplo "Answer a Collection ..." y resulta que el código corto pero erroneo devuelve por un lado una coleccion y por otro nil. *Aca estoy de acuerdo en que principalmente los accessors es estupido escribir comentarios, pero si los accessors son generados automaticamente, por que no hacer? y de esa forma ser consistentes en selector + comment + source en todo comportamiento. > >> y por ende escribir un par de comentarios no suele molestar a >> nadie. > > Escribirlo no, pero mantener duplicaciones si que molesta. Y ni hablar > lo molesto que es encontrarse un comentario desactualizado. Eso es bastante molesto, de hecho constantemente estoy buscando implementors para revisar cual es el comentario que debe ir, deberia hacerme una herramienta que me deje elegir automaticamente el comentario de alguno ya escrito... o algun tipo de anotacion o mecanismo de documentacion. Estoy de acuerdo en lo que decis aca y en otro mail que es un poco limitado el hecho de definir todo junto, mensajes, metodos, documentacion, en fin por ahora tengo eso y tampoco tengo tiempo para mejorar en ese punto. [...] > Todavía no conocí una mejor forma de documentar un sistema que los > unittests. Los unittests son ejemplos funcionando (y posibles de correr > en el debugger) de un feature determinado del sistema. Además, la > estructura de los tests (crear los objetos iniciales, hacer algo, > comprobar el resultado de ese algo), es una estructura muy interesante > para la documentación. > > ¿Ventajas? Los tests funcionan, y uno se entera inmediatamente cuando un > test se rompe. Lamentablemente no podemos decir lo mismo de los > comentarios. Bueno, mas o menos, tanto los comentarios como los tests deben tener mantenimiento. ¿O vos decis que haces los tests una sola vez y nunca mas los tocas, sólo los corres? ¿Por qué arreglar los tests y no los comentarios? Si cambio un metodo tambien cambio el comentario. Perdon si soy muy efusivo con esto pero en la practica cotidiana no tengo problemas de desactualización (sí de duplicación). Lo que si estoy de acuerdo es en el poder de los tests, las pocas veces que los hago, luego, *siempre* me resultan de inmejorable documentación. Saludos GallegO --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups-beta.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
