[clubSmalltalk] Re: Programando con Smalltak (El Libro)

Wed, 08 Nov 2006 04:28:06 -0800

Salió un poco largo el thread.
 
Bueno al principio opinaba lo mismo que tú, que era mejor crear comentarios en todos los métodos, hasta que me encontré con que los comentarios habían dejado de actualizarse a medida que los métodos evolucionaban.
 
Entonces me di cuenta que creando métodos más pequeños y con mejores nombres, en general no se requiere comentarios, excepto para decir lo que no se puede escribir directamente en el lenguaje de programación.
 
Me he encontrado con que alguien escribe:
 
i := i + 1. "incrementa i"
 
Eso es típico de comentarios redundantes. Conviene evitarlos porque no aportan información y distraen. Además que cuando se cambia el código por i := i + 2. típicamente uno aprende a despreciar mentalmente los comentarios porque sabe que no aportan, de modo que suele pasar que los comentarios quedan como reflejo de lo que alguna vez fue pero ya no es.
 
Por ejemplo:
 
message>>get: object "se conecta al servidor, espera un evento asociado al objeto y retorna el objeto procesado"
 
Sería más apropiado:
 
message>>connectWaitEventAndProcess: object
 
Esto tiene como ventaja que:
 
1. No es posible que llame al método y no sepa lo que hace.
2. El hecho de que el método tenga un nombre tan largo indica que tiene demasiada responsabilidad.
 
El problema ya estaba latente, esto sólo permite diagnosticarlo mejor.
 
En otras palabras los desarrolladores deben saber la diferencia entre métodos mutadores, inspectores, constructores, etc. y deben tratar de poner nombres descriptivos a sus métodos, evitando los comentarios (haciendo que sean innecesarios).
 
Eso, sumado al code review (primo del pair programming), las pruebas unitarias y detectar código repetido y eliminarlo, es suficiente para que el código no se deteriore con el tiempo.
 
Respecto de los castigos que se apliquen, en todas partes tienen sus costumbres. Nosotros "aplicamos corriente", porque de alguna manera se produce una reacción física cuando apretamos el timbre imaginario que aplica corriente, y lo mejor de todo es que parece chiste, pero el hecho de que se vea públicamente que cometiste un error es suficiente motivador para que el error no se repita.
 
En los pocos casos en que eso no basta se toman medidas más severas, sanciones administrativas, pero hace casi un año que no aplicamos ninguna.
 
Saludos,
Guillermo.

 
On 11/7/06, Esteban A. Maringolo <[EMAIL PROTECTED]> wrote:

Guillermo:

Efectivamente, asi lo dice Kent Beck, pero uno no le hace caso a todo
lo que dice, porque piensa por si mismo.

Aca si no comentás los métodos te cortamos los dedos (de manera que
tengas una escusa para no hacerlo) :-D

Saludos.



On 11/6/06, Guillermo Schwarz < [EMAIL PROTECTED]> wrote:
> Bueno, XP nació de conocidos Smalltalkers, y ellos manifiestan que no es
> necesario comentar los métodos (si al final nadie lo lee), con las
> siguientes salvedades:
>
> 1. Comentarios de clase.
> 2. Comentarios de interfaces y de clases "fachada".
>
> ¿Cómo se las arreglan sin comentarios?
>
> Intention revealing selectors...
>
>
> On 11/6/06, GallegO <[EMAIL PROTECTED]> wrote:
> >
> > Hola:
> >
> > Hablando de eso, nosotros solemos hacer "mini charlas" de Smalltalking
> > solo para elegir nombres, ayudados del diccionario de sinónimos (Maringa
> > si podes tira el link :), es una de las mejores herramientas.
> > Creemos que como decía la propaganda "Un buen nombre es lo mejor que uno
> > puede tener" aunque sea argumento o variable de instancia.
> >
> > En el caso de ejemplo de unasAgendas a veces, ademas de las opciones que
> > evaluaron antes, tambien hay que tener en cuenta poner simplemente
> > aCollection o collection, nada más, pero creo que depende mucho del
> > contexto, la implementación, si hay polimorfismo, etc.
> > Para tener en cuenta Smalltalk with style, como decia Guiye, con la
> > salvedad (sobre este libro) que IMHO los comentarios de los metodos van
> > en todos, sean setters y getters o no, ya que el no ponerlos en los
> > accessors da pie a tampoco ponerlos en metodos "obvios" y asi en
> > adelante degenerar en no ponerlos...
> >
> > Obviamente respeto cualquier opinión contraria.
> >
> > Saludos
> > GallegO
> >
> > Esteban A. Maringolo escribió:
> > > Creo que es una cuestión de estilos, pero los nombres de las variables
> > > de instancias no se nombran como unBoolean, unPerro, etc.
> > >
> > > Sí se nombran asi los argumentos y variables temporales de un método.
> > >
> > > Repito, es una cuestión de convenciones de donde se trabaje.
> > >
> > > Saludos.
> > >
> > > On 11/6/06, Guillermo Schwarz < [EMAIL PROTECTED] > wrote:
> > >> En Smalltalk es usual que el nombre de la clase se utilice dentro del
> nombre
> > >> de la variable.
> > >>
> > >> Así por ejemplo, sabemos que unaAgenda es una variable que apunta a una
> > >> instancia de la clase Agenda.
> > >>
> > >> Sin embargo si tenemos OrderedCollection que contiene agendas,
> unaAgendaList
> > >> me parece màs revelador de la intenciòn, ademàs que es màs fàcil
> confundir
> > >> unaAgenda con unaAgendas o unasAgendas, que con unaAgendaList.
> > >>
> > >> Finalmente està la cuestiòn de que puede ser unaAgendaSet, unaAgendaMap
> (o
> > >> unaAgendaDict para los màs puristas), etc. de modo que pasa a se màs
> difìcil
> > >> usarlo mal.
> > >>
> > >> Saludos,
> > >> Guillermo.
> > >>
> > >>
> > >>
> > >> On 11/6/06, Diego Gomez Deck <[EMAIL PROTECTED] > wrote:
> > >>> Hola Santiago,
> > >>>
> > >>> Si, definitivamente "Agendas" y "unaAgenas" suenan horrible.
> > >>>
> > >>> El tema es que elegí no prestar mucha atención a los nombre en ese
> punto
> > >>> (donde el usuario todavía no metió mano en Smalltalk) para pasar a
> > >>> "manos a la obra" lo más rápido posible.
> > >>>
> > >>> Si hubiese tenido que hablar de convenciones de nombres de clases,
> > >>> variables de instancia, como comentar clases, como comentar métodos,
> > >>> como comentar mensajes, etc no hubiese podido lograr que el lector
> (del
> > >>> libro) meta mano en ST cuando antes.
> > >>>
> > >>> Saludos,
> > >>>
> > >>> -- Diego
> > >>>
> > >>>> Hola gente. Hola Diego. Hace muchos años que programo en Smalltalk.
> > >>>> Siempre con VisualAge. La verdad que por cuestiones que ya se
> trataron
> > >>>> en esta lista, nunca me sentí atraído por Squeak.
> > >>>> Estos días empecé a leer tu libro y me sirvió de motivación para
> meter
> > >>>> mano en Squeak. La verdad que te felicito por tu trabajo y te
> > >>>> agradezco por tu valiosísimo aporte.
> > >>>> Concretamente quería opinar sobre el ejemplo que comienza desde la
> > >>>> página 59, "3.2 Parser de XML basado en una Pila". Llegando a la
> > >>>> página 60, me llamó la atención la clase "Agendas". Hubiera creído
> que
> > >>>> un mejor nombre sería AgendasManager o algún otro, pero en singular.
> > >>>> De hecho, unaAgendas no suena bien. Claro que no soy un erudito, pero
> > >>>> quería comentar y conocer de otras opiniones.
> > >>>>
> > >>>> Un abrazo para todos,
> > >>>> Santiago
> > >>>
> > >>> --
> > >>> ==========================================
> > >>> Diego Gomez Deck
> > >>> ------------------------------------------
> > >>> http://diegogomezdeck.blogspot.com/
> > >>> http://smalltalk.consultar.com/
> > >>> ==========================================
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> >
> >
> >
> >
> > > >
> >
>


--
Esteban A. Maringolo
[EMAIL PROTECTED]


--~--~---------~--~----~------------~-------~--~----~
  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.
-~----------~----~----~----~------~----~------~--~---

Responder a