Fwd: Código bonito [Comentarios]

[Juan Carlos Quijano Abad]

Buenos días,

Solo para compartir mi experiencia real. Acabo de recuperar un código de hace más de un año y quiero que lo veaís, y a ver quien es el guapo que me dice qué es lo que hace. O, mejor aún, quien es el guapo que me dice como mejorar su semántica para que sea autodocumentado... :)

    Protected Sub gvGrid_RowDataBound(ByVal sender As Object, ByVal GridViewRowEventArgs As System.Web.UI.WebControls.GridViewRowEventArgs) Handles gvGrid.RowDataBound
        Dim numCeldas As Integer

        If GridViewRowEventArgs .Row.RowType = DataControlRowType.DataRow Then
            numCeldas = e.Row.Cells.Count
            For x As Integer = 0 To numCeldas - 2
                GridViewRowEventArgs .Row.Cells(x).Attributes.Add("onclick", Page.ClientScript.GetPostBackEventReference(sender, "Editar$" & CType(e.Row.FindControl("lblidAmbito"), Label).Text & "@" & CType(e.Row.FindControl("lblDescripcion"), Label).Text))
            Next

            e.Row.Style.Add("cursor", "hand")

            If CType(e.Row.FindControl("lblidAmbito"), Label).Text = IdAmbito Then
                GridViewRowEventArgs .Row.BackColor = Drawing.Color.FromName("#F9DD9D")
            End If

        End If

    End Sub

--
Un saludo
Juan Quijano

[Abel Muiño]

Ahí va mi adivinación (soy un VB-noob, be patient!)

Creo que el código hace dos cosas:
- Registrar una acción al hacer click en cada fila de una tabla excepto la última. Esta acción dispara un evento asociado a una cadena compuesta con los valores de la tabla (?) -> editar$ambito@descripción
- Cambiar la fuente de la fila seleccionada

Dejando a un lado convenciones de nombres de .NET (que no domino mucho, pero creo que es costumbre incluir el tipo de la variable el el nombre... como en "lblidXXX"  (entiendo que es un "label id"), yo haría dos cosas para empezar:

- Si he acertado en lo que hace el código, separar cada cosa.
- Todos las cadenas que se pasan a los métodos movidas a constantes con un buen nombre.
- Uniformizar convenciones de nombre de parámetros (la mayoría tienen nombres cortos -pero comprensibles- y están con minúsculas, pero GridViewRowEventArgs está en mayúsculas y es bastante largo... mi background en Java me hace ver un nombre de clase en lugar de una variable).

No veo de dónde vienen algunas variables (e, IdAmbito... supongo que son globales)

Pseudo-code:

gvGrid_RowDataBound(sender, args) {
  if isValidRowType(args) {
    numCeldas = e.Row.Cells.Count
    registerPostBackEvent(sender, args)

    e.Row.Style.Add("cursor", "hand")

    highlightRowIfNeeded()
  }
}

2009/11/6 Juan Carlos Quijano Abad <juancarl...@gmail.com>

--
Abel Muiño - http://ramblingabout.wordpress.com/

[Juan Carlos Quijano Abad]

Buenasss,

Bravo!!

Permíteme Abel, esperar alguna otra respuesta y continuo el ejercición práctico argumentando el porque de un nombre como GridViewRowEventArgs.

--
Un saludo
Juan Quijano

[José Manuel Beas]

Pues yo creo que es un programa de inteligencia artificial que cuando le llega un evento (Event) del tipo "Arg, esto es una m..." (Args) lo mete en una red (Grid) y nos permite verlo (View). De otro modo, sólo lo oiríamos en la lejanía...

Feliz fin de semana a todos (fin de semana largo para los de Madrid) :-)

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com

[Juan Carlos Quijano Abad]

Buenas,

jajaja, no me esperaba ni más ni menos de tí XD

--
Un saludo
Juan Quijano

[Alfredo Casado]

El nombre del metodo es digamos poco explicativo "gvGrid_RowDataBound", ¿es obligatorio por el framework llamarlo así o se puede cambiar? (de vb.net ni idea y viendo el código se me quitan las ganas xd).

luego parece que se hacen varias cosas:
 - Si las filas no son de tipo "data" no se hace na
 - establecer un evento en cada fila
 - cambiar el icono del cursor
 - si ambito vale no se que (es una propiedad de clase IdAmbito no?) entonces cambiar el color de fondo en el grid

luego hay alguna cosa más que afea un poco, llamar a las instancias igual que a la clase es una mala costumbre,

hombre ponle un nombre que tenga sentido en tu contexto, como no conozco tu contexto ni exactamente que es un cacharro de esos lo llamo "grid" que por lo menos es más cortito y da la misma información: ninguna.

Protected Sub gvGrid_RowDataBound(ByVal sender As Object, ByVal grid As System.Web.UI.WebControls.GridViewRowEventArgs)  Handles gvGrid.RowDataBound

         
           if  not esUnGridConFilasDeDatos(grid) 
              return;
           End if

           asociarEventoParaNoSeQueACeldasDelGrid(grid);
           cambiarEstiloDelCursorPoniendoUnaManita(grid);
           cambiarColorDelGridSiElAmbitoValeNoSeQue(grid);

    End Sub

Y luego en esos metodos te preocupas por los detalles, que en pequeñas dosis todavía pero el API del gridRowEventPeich ese es una cosa fea, fea y usarlo mucho de sopeton en un mismo metodo tira para atras.

[José Manuel Beas]

Don't feed the troll!

[German DZ]

Es broma verdad????? Colocar ese bloque de código en un correo llamado Código Bonito.

La verdad que es horrible que haya que tener código server side, para agregar funcionalidad client side a un control de presentación de información. Te obliga a llevar la complejidad del código cliente al server.

Y digamos que la notación VB.NET es mucho más "larga" que la C# sin aportar demasiada legibilidad.

2009/11/6 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Xavi Gost]

Don't feed the Troll

[Juan Carlos Quijano Abad]

Ups, no pensé que Xai y JMB se molestaran.

Doy por terminado mi agumentación en pro de los comentarios.

--
Saludines
Juan Quijano

[Harald Messemer]

Para evitar el assert que comprueba si el grid es del tipo que quieres
manipular, podrias crear una subclase de la clase grid que pasas como
parametro. Asi el codigo seria aun mas legible y la comprobacion si el
tipo es correcto te lo hace el compilador.

Un saludo,
Harald

2009/11/6, José Manuel Beas <jose....@gmail.com>:

[José Manuel Beas]

Yo he pedido no alimentar al troll porque aún estoy esperando saber por qué Juan Carlos ha iniciado el hilo. Si no va a dar argumentos, yo también puedo destapar el arcón donde guardo mi "codex horribilis". Pero sin más "insight", me parece simplemente una aportación sin valor.

Y lo digo con cariño, Juan Carlos. No te lo tomes a mal.

[Juan Carlos Quijano Abad]

Buenassss,

Siguiendo el consejo de Xavi, realizo la argumentación de la necesidad de comentarios que es el objetivo de este "experimento",


1. Existen muchos lenguajes de programación y casi ninguno tiene un nivel suficientemente alto de lenguaje natural como para poder ser autoexplicativos de forma autónoma. (Que yo conozca el Prolog y los rumores del M).
2. Si hago el mismo código en otro lenguaje diferente (invito a hacer la misma función en otros lenguajes y así comparamos) será igual o más dificil de comprender lo que hace, ya que el código es autodocumentado solamente para las personas que conocen ese lenguaje (obviemos a todo no programador porque entonces sería de perogrullo el que no sea capaz de leer código).
3. Como se ha visto en las respuestas al experimento, si hay 10 programadores frente a un problema, habrá 10 soluciones diferentes con 10 codificaciones diferentes :).
4. No solamente el lector no siempre conoce el lenguaje, sino que no conoce las estructura o formas de hacer las cosas. Y que son muy dificiles de entender sin ayuda. Por ejémplo las cadenas Lambda en C#, el uso de patrones de arquitectura, codificaciones propias de los frameworks, la recursividad, etc.
5. El uso de librerias de clases en POO impide el libre uso de nombres en la codificación. Y también las reglas básicas de legibilidad de código como no poner nombres muy largos.
6. En mi opinión, añadir código o partir el método con el objetivo de clarificar la autodocumentación (hacer un método que encapsule los métodos de nombres espantosos) no es solución porque "el comentario no compila pero el código si". Además de dificultar la lectura del código y su proposito al fragmentarlo en diferentes métodos, clases o incluso páginas físicas.

Básicamente, pienso que estaré encantado el día que pueda leer un código como leo un comentario. Pero lo veo aún lejano. Y mantengo que no hay nada mejor para explicar un código que un comentario.

Por supuesto los comentarios tienen un lado muy oscuro y perverso, que es cuando le bajas demasiado el nivel de abstracción y además no lo mantienes:
// Carga el valor de la fecha en la variable de fechaInicial
Dim idFecha as integer = "10/10/2009"

Pero creo que son muchas más las ventajas

Y a continuación el código original, comentado y resaltado en negro los terminos que puedo cambiar. Lo demás me obliga el código y los controles con los que se comunica. En C# el mismo código es aún más limitado en su modificación.

    ''' <summary>
    ''' Evento de carga de datos en las filas del Grid de Ambito.
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks>
    ''' Aquí se consigue que se pueda editar una fila pulsando sobre ella.
    ''' Pero dejando a discreción sobre qué celdas se va a omitir este comportamiento.
    ''' </remarks>
    Protected Sub gvGrid_RowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs) Handles gvGrid.RowDataBound
        Dim numCeldas As Integer

        '' Si es una fila de datos.
        If e.Row.RowType = DataControlRowType.DataRow Then

            ''Cuento el número de celdas que componen la fila.
            numCeldas = e.Row.Cells.Count

            '' Cargo el comportamiento en cada celda.
            '' En este caso en todas menos en la última que es la de borrado.

            For x As Integer = 0 To numCeldas - 2

                e.Row.Cells(x).Attributes.Add("onclick", Page.ClientScript.GetPostBackEventReference(sender, "Editar$" & CType(e.Row.FindControl("lblidAmbito"), Label).Text & "@" & CType(e.Row.FindControl("lblDescripcion"), Label).Text))
            Next

            '' Le indico que en utilice el cursor de selección cuando se pase por encima.

            e.Row.Style.Add("cursor", "hand")

            '' Pinta la fila resaltada si es está seleccionada.

            If CType(e.Row.FindControl("lblidAmbito"), Label).Text = IdAmbito Then

                e.Row.BackColor = Drawing.Color.FromName("#F9DD9D")

            End If

        End If

    End Sub

P.D. Perdón por la forma de plantear el experimento, he "trampeado" los resultados al mostrar el proposito despues de las respuestas.

P.D. Si apetece seguir con el debate, lo más interesante sería rebatir los argumentos con trozos de código para mantener el nivel de concreción y no perdernos en "buenas ideas". O, incluso, buscar un foro de programación más adecuado a la temática.

[alberto]

Hola.

2009/11/6 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Buenassss,

Siguiendo el consejo de Xavi, realizo la argumentación de la necesidad de comentarios que es el objetivo de este "experimento",


1. Existen muchos lenguajes de programación y casi ninguno tiene un nivel suficientemente alto de lenguaje natural como para poder ser autoexplicativos de forma autónoma. (Que yo conozca el Prolog y los rumores del M).

2. Si hago el mismo código en otro lenguaje diferente (invito a hacer la misma función en otros lenguajes y así comparamos) será igual o más dificil de comprender lo que hace, ya que el código es autodocumentado solamente para las personas que conocen ese lenguaje (obviemos a todo no programador porque entonces sería de perogrullo el que no sea capaz de leer código). 

No es el lenguaje el que tiene que ser autoexplicativo, sino tu código. Que luego haya quien defienda que unos lenguajes meten menos ruido que otros es otra historia...

4. No solamente el lector no siempre conoce el lenguaje, sino que no conoce las estructura o formas de hacer las cosas. Y que son muy dificiles de entender sin ayuda. Por ejémplo las cadenas Lambda en C#, el uso de patrones de arquitectura, codificaciones propias de los frameworks, la recursividad, etc.

El código lo programamos para que lo lean otros programadores. Programadores competentes además. Si programas con gente que no conoce las cosas que comentas, no creo que lo arregles añadiendo comentarios.

5. El uso de librerias de clases en POO impide el libre uso de nombres en la codificación. Y también las reglas básicas de legibilidad de código como no poner nombres muy largos.

Lo de las librerías no lo he entendido, supongo que te refieres a las llamadas a otras librerías¿? Si necesitas comentar una llamada a una librería para explicar lo que hace, malo... Y en tal caso, puede que prefieras crear un wrapper sobre la misma.

Lo de la legibilidad del código lo dirás tú. Uso nombres tan largos como sea necesario, y el código es bastante más legible que sin ellos. Por el contrario el usar nombres cortos y abreviaturas sí reduce la legibilidad.

6. En mi opinión, añadir código o partir el método con el objetivo de clarificar la autodocumentación (hacer un método que encapsule los métodos de nombres espantosos) no es solución porque "el comentario no compila pero el código si". Además de dificultar la lectura del código y su proposito al fragmentarlo en diferentes métodos, clases o incluso páginas físicas.

No dificulta la lectura, muy al contrario. Se ha repetido unas cuantas veces los últimos días, separa los niveles de abstracción.

Y a continuación el código original, comentado y resaltado en negro los terminos que puedo cambiar. Lo demás me obliga el código y los controles con los que se comunica. En C# el mismo código es aún más limitado en su modificación. [...]

Extract method. Hasta que duela. :)

[José Manuel Beas]

100% con Alberto.

"¡Extract Method hasta que duela!. ¡Cómo mola!

[Harald Messemer]

Me parece que el caso de utilizar una libreria de otros, si no hay
otro remedio, es uno de los casos donde los comentarios son utiles y
necesarios y si utilizas un wrapper, que me pareceria normalmente
recomendable, los tendras que poner en el wrapper.

En general hablando de comentarios, creo se han ido mezclando los
conceptos un poco, en este hilo y los demas del tema.

Me refiero a que una cosa es que un codigo es tan ofuscado para
requiera comentarios para ser comprensible y otra cosa es que el
programador considera de utilidad de anadir comentarios, a pesar que
algunos ya entienden el codigo asi.

Vamos, creo que el segundo caso da mucho menos lugar para critica.
Creo que todo el mundo valora un buen codigo con una buena
documentacion.

Un saludo,
Harald

PD: el ejemplo creo que si quedaria mejor con extract method, uso de
un wrapper y especializacion de la clase grid :-) pero es una opinion
subjetiva.

2009/11/6, alberto <albert...@gmail.com>:

[Abel Muiño Vizcaino]

El 06/11/2009, a las 13:08, José Manuel Beas escribió:

Yo he pedido no alimentar al troll porque aún estoy esperando saber por qué Juan Carlos ha iniciado el hilo. Si no va a dar argumentos, yo también puedo destapar el arcón donde guardo mi "codex horribilis". Pero sin más "insight", me parece simplemente una aportación sin valor.

Mmmm.... en el contexto de los últimos mensajes a la lista, a mi me ha parecido evidente que era un "caso de prueba" de todo lo que ha comentado (y de nada en concreto).

Creo que se han enviado mensajes bastante menos productivos (como este mismo de quien firma, so don't feed me).

Por pura nettiquette... si un tema no os aporta, no lo contestéis... Troll es algo bastante fuerte (o quizá sólo me lo parece a mi).... y si nadie me lo llamó cuando entré "a saco" con mis escepticismos en foro-agiles, no veo motivo para llamárselo a nadie porque inicie un "desafío de comprensión del código".

Fin del off-topic y de la procrastinación. A currar un poco que de eso depende mi pan ahora :-)

[Vicenç Garcia]

Buenas,

yo siempre pongo comentarios e intento que la gente los ponga. No tanto para las funciones que con su nombre són autoexplicativas sinó para explicar las precondiciones, valores de retorno, etc. Y cómo en unas quantas funciones los necesito, pués los pongo en todos y así queda más homogéneo. Quizá es un poco pérdida de tiempo, pero tampoco lo veo tan grave.

Cómo en todo ( o casi todo ), no se tiene que ser talibán de ninguna opción.

Saludos,

Vicenç

2009/11/6 Harald Messemer <harr...@gmail.com>

--
Vicenç García
http://devnettips.blogspot.com

[Abel Muiño Vizcaino]

El 06/11/2009, a las 14:52, Juan Carlos Quijano Abad escribió:

5. El uso de librerias de clases en POO impide el libre uso de nombres en la codificación. Y también las reglas básicas de legibilidad de código como no poner nombres muy largos.

El nombre debe ser autoexplicativo. Y yo añadiría: en su contexto. Por ejemplo (vamos con sintaxis java 1.4, que todo el mundo la lee :-) )

public int totalFactura(Factura f) {

int out = 0;

for (int i = 0; i < 10; i++) {

LineaFactura l = f.getLinea();

   out += l.getPrecio() * l.getCantidad();

}

return out;

}

El nombre del parámetro es irrelevante para calcular el total, así que "f" es suficiente. Lo mismo para la variable del bucle "i" o la línea que se está tratando "l". El valor de retorno "out" es corto pero significativo (además, permite seguir un convenio... llamarlo "total" es tb explicativo, pero no sería uniforme en todos los métodos).

Por el contrario, otras veces necesitarás nombres largos... especialmente si el problema a resolver no es "de gran difusión" (se me ocurren cosas como cálculos bancarios o de inversión...).

6. En mi opinión, añadir código o partir el método con el objetivo de clarificar la autodocumentación (hacer un método que encapsule los métodos de nombres espantosos) no es solución porque "el comentario no compila pero el código si". Además de dificultar la lectura del código y su proposito al fragmentarlo en diferentes métodos, clases o incluso páginas físicas.

En mi caso, he notado que soy bastante "top-down". Para mi es más sencillo pensar en lo general e ir bajando a lo particular... es decir, no descompongo un método en varios para que sea legible... lo hago por mi forma de pensar (que, no sé si por casualidad o por entrenamiento inconsciente, da como resultado un código legible). Quizá esto sea una "aproximación a TDD"... escribir el algoritmo de alto nivel que no compila y completarlo hasta que sí compila :-)

public int invitadosABoda(Pareja p) {

  return invitadosPorParteDe(p.novio) + invitadosPorParteDe(p.novia);

}

(no es buen diseño, I know... pero sólo es un ejemplo de ir "top-down")

Básicamente, pienso que estaré encantado el día que pueda leer un código como leo un comentario. Pero lo veo aún lejano. Y mantengo que no hay nada mejor para explicar un código que un comentario.

Cada cosa en su sitio.

Siempre hay código que necesita ser comentado (o que agradece ser comentado), especialmente en las partes más "arcanas". Y "arcano" tendrá distinta definición en cada equipo. Por ejemplo, yo he visto como los primeros proyectos al adoptar una tecnología se plagaban de comentarios que iban desapareciendo cuando el equipo entendía mejor la tecnología. Los comentarios sirvieron como ayuda a difundir el conocimiento... y luego se volvieron superfluos.

Y hasta aquí puedo leer!

[Alfredo Casado]

Me resulta increible que alguien crea que algo como esto es ni medio razonable:

Este código es realmente HORRENDO, y los comentarios no lo arreglan ni de lejos, sin comentarios había entendido lo mismo que entiendo con ellos: QUE HAY QUE REFACTORIZAR ESO PERO YA!!.

[Alberto Peña]

El 2009/11/6 Abel Muiño Vizcaino <amu...@gmail.com> dijo

El nombre debe ser autoexplicativo. Y yo añadiría: en su contexto. Por ejemplo (vamos con sintaxis java 1.4, que todo el mundo la lee :-) )

public int totalFactura(Factura f) {

int out = 0;

for (int i = 0; i < 10; i++) {

LineaFactura l = f.getLinea();

   out += l.getPrecio() * l.getCantidad();

}

return out;

}

El nombre del parámetro es irrelevante para calcular el total, así que "f" es suficiente. Lo mismo para la variable del bucle "i" o la línea que se está tratando "l". El valor de retorno "out" es corto pero significativo (además, permite seguir un convenio... llamarlo "total" es tb explicativo, pero no sería uniforme en todos los métodos).

 

Yo no estoy de acuerdo. Las variables f, l, etc. no me dicen nada. Escribir es gratis y no creo que haya que "ahorrar" en caracteres. En lugar de f, escribe factura. En lugar de l escribe linea. Incluso, en lugar de out escribe total, que es lo que estás calculando (lo del convenio no me gusta, estoy harto de quitar variables bRes del código...). Para mí,  el código debe ser bonito siempre, no a veces sí y a veces no (por muy sencillo que sea dicho código).

Un saludo

PS: Creo que esto se desvía de lo de los comentarios. Respecto a eso, los lenguajes no deberían permitir los comentarios :P

[Alfredo Casado]

Te respondo con más tranquilidad que estoy aburrido mientras termina la lavadora xddd

2. Si hago el mismo código en otro lenguaje diferente (invito a hacer la misma función en otros lenguajes y así comparamos) será igual o más dificil de comprender lo que hace, ya que el código es autodocumentado solamente para las personas que conocen ese lenguaje (obviemos a todo no programador porque entonces sería de perogrullo el que no sea capaz de leer código).

En este caso la "dificultad" del código no esta en el lenguaje, no se vb.net pero if, for, end if etc,etc es algo que comprende cualquier programador. La dificultad de compresión del código es culpa del API que estas usando, como todo framework/librería de uso general tiene metodos muy flexibles para ser usados en muchos contextos, estos métodos no dicen nada del problema concreto con el que estas tratando y esto es lo hace a ese código ilegible y feo con ganas. La solución es recubrir el API general con uno más especifico, con llamadas a funciones que oculten lo detalles o mejor aún con clases wrapper que encapsulen el componente en cuestion y te ofrezcan métodos con sentido en tu contexto.

3. Como se ha visto en las respuestas al experimento, si hay 10 programadores frente a un problema, habrá 10 soluciones diferentes con 10 codificaciones diferentes :).

Eso no implica que todas sean buenas :P.

4. No solamente el lector no siempre conoce el lenguaje, sino que no conoce las estructura o formas de hacer las cosas. Y que son muy dificiles de entender sin ayuda. Por ejémplo las cadenas Lambda en C#, el uso de patrones de arquitectura, codificaciones propias de los frameworks, la recursividad, etc.

Si hablamos de conocimientos generales de programación, recursividad, inyección de dependencias, AOP etc,etc, pues obviamente si el que lo lee es un programador debera entender esas construcciones, es como entender un if o un for, si no entiendes eso pues logicamente no entenderas el código, que estudie primero. Otro tema son los frameworks/librerías, que no es conocimiento general sino especifico y hay miles de millones, por eso conviene recubrirlos de algún modo como decia antes.

5. El uso de librerias de clases en POO impide el libre uso de nombres en la codificación. Y también las reglas básicas de legibilidad de código como no poner nombres muy largos.

Lo mismo otra vez, recubre. Eso de que no poner nombres largos es una "regla basica de legibilidad"..., la longitud en el nombre de un metodo o variable es irrelevante, importa que exprese su intención, ¿¿el tamaño que más da??. (evidentemente si ocupa 200 caracteres hay algo mal, pero no en el nombre en si, si no que es tan largo porque ese metodo tiene demasiadas responsabilidades).

6. En mi opinión, añadir código o partir el método con el objetivo de clarificar la autodocumentación (hacer un método que encapsule los métodos de nombres espantosos) no es solución porque "el comentario no compila pero el código si". Además de dificultar la lectura del código y su proposito al fragmentarlo en diferentes métodos, clases o incluso páginas físicas.

¿En serio te parece más legible el churro de antes comparado con una función con 4 llamadas a métodos que expresan claramente el objetivo?, eso no puedo entenderlo. Yo cuando leo tu metodo no necesito la información exacta de como se pone la manita del cursor en el api de vb.net, me basta con saber que se pone la manita y si necesito los detalles me voy al método que los contiene.

Algunos ejemplos concretos sobre el código, al principio de la función pones:

''' Pero dejando a discreción sobre qué celdas se va a omitir este comportamiento.

¿A que discrección?, luego si lo lees te enteras de que en la ultima fila no se pone porque es de borrado, pues pon eso en el comentario, una cosa es escribir código como un ensayo, y otra es que el primer comentario te deje con intriga para que sigas leyendo xddd

Otro ejemplo:

'' Cargo el comportamiento en cada celda.
 '' En este caso en todas menos en la última que es la de borrado.

            For x As Integer = 0 To numCeldas - 2

                e.Row.Cells(x).Attributes.Add(

"onclick", Page.ClientScript.GetPostBackEventReference(sender, "Editar$" & CType(e.Row.FindControl("lblidAmbito"), Label).Text & "@" & CType(e.Row.FindControl("lblDescripcion"), Label).Text))
            Next

Un comentario que dice que se "carga el comportamiento" pero no dice que comportamiento se carga, si me leo la cabecera de la función descubro que el comportamiento es "hacer las filas editables", parece un puzzle leñe.

Por ejemplificar lo del wrapper, te haces una clase que encapsule la fila del grid y le pones métodos con sentido en tu contexto, algo así:

FilaGridAmbitos filaGrid = new FilaGridAmbitos(e);
filaGrid.hacerCeldasEditables();
filaGrid.resaltarSiEstaSeleccionada(idAmbito);
filaGrid.habilitarCursorSeleccionCuandoPaseElRatonPorEncima();

No es la caña tampoco, pero queda claro que estas tratando una fila del grid y que haces sus celdas editables, la resaltas si esta seleccionada y le pones el cursor cuando se pase por encima. Despues de escudriñar el código eso es lo que hace, el siguiente que se lo encuentre no tendrá que andar media hora escudiriñando que a lo mejor no tienen tanto tiempo libre como yo esta tarde xd.

Aunque lo suyo probablemente seria hacer un wrapper del grid completo y que el contralara el evento y tal y pascual, pero para eso tendría que conocer mejor el framework y el problema, pero vamos simplemente con esto da menos panico al pobre que le toque modificar luego ese código.

El código que has puesto es un ejemplo claro de precisamente lo que siempre critico de los comentarios, usarlos porque no dedicamos el suficiente esfuerzo a hacer el código verdaderamente legible. Si te sigue pareciendo tu código más legible/mantenible/bonito que las cuatro lineas de antes ya no se como explicartelo xddd.

[Abel Muiño Vizcaino]

El 06/11/2009, a las 20:56, Alfredo Casado escribió:

Lo mismo otra vez, recubre.

Este consejo lo veo muy bueno y muy malo.

Muy bueno porque hace el código legible y oculta las complejidades del framework (y no me extiendo más pq creo que todos vemos las virtudes)

Muy malo porque un recubrimiento es, por obligación, menos potente que el original (si tiene la misma potencia y todavía limita la complejidad, tienes una joya vendible).

Lo que he visto que ocurre es que la capa de recubrimiento es tan desconocida como la original para los nuevos reclutas. Y, peor aun, no hay resultados en google sobre sus problemas o cómo usarla.

De nuevo, la mejor solución depende del contexto. Si tienes un equipo con poca rotación que es capaz de crear ese recubrimiento (que podríamos asimilar a un "DSL", ahora que están tan de moda,  específico al problema) y, además, tienen conocimiento de lo que hay debajo de ese recubrimiento (con lo que pueden completar las abstracciones cuando sea necesario), entonces sí.

Si estás en la empresa media... bastante tienes con encontrar a alguien medianamente competente en algún framework "no-inventado-aquí". Creo que no es buena pauta buscar a gente competente para que tenga que aprender las particularidades del recubrimiento. Y ADEMÁS conocer la capa que encapsula para poder añadir al recubrimiento cuando sea necesario.

Si el mundo fuera ideal, haríamos una cosa. Como no lo es, nos adaptamos a lo que hay.

O nos montamos una empresa todos los de la lista y nos matamos a ver quien hace la función más bonita ;-)

[Alfredo Casado]

Precisamente el recubrimiento sirve para que "los nuevos reclutas" entiendan el código, los recubrimientos están para facilitar las cosas, si haces un recubrimiento igual de complejo y feo que el original pero además no salen sus resultados en google pues entonces lo que ocurre es que has echo un mal recubrimiento, no que hacer recubrimientos este mal.

Pero vamos, tampoco consiste en tirarse 3 meses para hacer un "framework corporativo que recubra hibernate", se trata de en un proyecto especifico hacer un recubrimiento especifico que sirva para clarificar las intenciones del código en puntos concretos para precisamente que lo entiendan hasta los más torpes. Es que de eso va esto de la POO: de abstracción.

Lo que no entiendo el intento de justificar algo mal echo porque la gente es muy torpe, estamos hablando de la mejor forma de hacer un código bonito. Si estas en el contexto de "empresa media" donde la gente es muy torpe, pues tienes la opción de dejarles que se sigan hundiendo en el barro haciendo código ilegible o tratar de enseñarles a hacerlo un poco mejor.

[Abel Muiño Vizcaino]

El 06/11/2009, a las 22:25, Alfredo Casado escribió:

Lo que no entiendo el intento de justificar algo mal echo porque la gente es muy torpe, estamos hablando de la mejor forma de hacer un código bonito. Si estas en el contexto de "empresa media" donde la gente es muy torpe, pues tienes la opción de dejarles que se sigan hundiendo en el barro haciendo código ilegible o tratar de enseñarles a hacerlo un poco mejor. 

Mi forma de verlo es que es más fácil enseñarles a entender el framework "real" (sin nada que lo tape) que enseñarles a manejar el recubrimiento (y que no sepan extenderlo cuando haga falta).

La verdad es que tengo un "bias" bastante fuerte de haberme pegado con recubrimientos problemáticos heredados (algunos sin código fuente que poder mejorar)... así que tampoco me hagas mucho caso :-)