Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Saturday, June 30, 2007
I hate code folding
Me ha sorprendido que al darle a buscar la frase "I hate code folding" en Google no obtuviera ningún resultado. ¿Realmente soy la única persona en el mundo que odia el Code Folding?
Pues nada, a partir de ahora Google sí devolverá un resultado: el de esta entrada. La cual se va a convertir en un manifiesto en contra de las regions.
Realmente, ¿qué tiene de bueno poder agrupar una serie de bloques bajo un nombre determinado? Cuando abro un fichero con código, lo primero que quiero hacer es leer código, no tener que pinchar en un estúpido widget con un [+] para poder verlo. Menos mal que MonoDevelop aún no soporta esta funcionalidad (pero VStudio sí, ¡qué horror!) y mejor que no la soporte nunca.
Mucha gente puede pensar a partir de mis comentarios que lo que tendría que pasar es que mi IDE favorito que implemente esta funcionalidad pudiera ser configurable para mostrar las regions de entrada abiertas en lugar de cerradas. Pero en ese caso, me reitero, ¿de qué sirven?
Entendedme, no es que esté en desacuerdo en que la gente pueda coger y ocultar la implementación de un método, viendo sólo su prototipado, para así ver la clase de una forma más global y general (si lo hace así con el resto de los métodos), pero ¿las regiones que puede escribir el propio programador de que sirven? Sirven, de hecho, para provocarle malos hábitos. De siempre es sabido que cuanto menos código tenga una clase o un método, más intuitivo y mejor escrito y modular es un código, ¿y cuando son útiles las regions? ¡Cuando el código es completamente farragoso, largo y poco estructurado! (aka spaghetti code).
¿Y poder ocultar la implentación de una clase entera? También lo veo inútil, porque yo tiendo a escribir una clase por fichero (aunque C# soporte varias, me gusta la rigidez de Java en ese sentido), cosa que parece más fácil de entender de cara a programadores que en el futuro tengan que entender tu código.
Conclusión: el único "ocultamiento" de código que me gustaría, sería aquel que pudiera alternar entre (a) Ver el código tal cual, (b) Ver sólo los prototipos de tus métodos de tu clase.
PD: Muchas gracias a todos los amigos y lectores de mi blog que me han animado a continuarlo. No es que hubiera querido dejar de escribir, sino que estos meses me ha resultado imposible sacar tiempo para escribir en él (a pesar de tener muchos artículos casi listos para publicar, pero aún en modo borrador), por cuestiones de intenso (aunque motivador) trabajo y de mudanza. De todos modos, sí he escrito alguna que otra actualización a entradas ya existentes, cosa que sólo se puede dar uno cuenta fácilmente si utiliza la suscripción RSS.
Actualización 05-JUL-2007: Resulta que hoy he encontrado otro inconveniente en esto del Code Folding junto con un compañero de trabajo. ¡Un bug de VStudio al buscar texto con el editor de VB.NET! Si la region no estaba abierta, VStudio engañaba al usuario diciéndole que el texto no se podía encontrar.
Pues nada, a partir de ahora Google sí devolverá un resultado: el de esta entrada. La cual se va a convertir en un manifiesto en contra de las regions.
Realmente, ¿qué tiene de bueno poder agrupar una serie de bloques bajo un nombre determinado? Cuando abro un fichero con código, lo primero que quiero hacer es leer código, no tener que pinchar en un estúpido widget con un [+] para poder verlo. Menos mal que MonoDevelop aún no soporta esta funcionalidad (pero VStudio sí, ¡qué horror!) y mejor que no la soporte nunca.
Mucha gente puede pensar a partir de mis comentarios que lo que tendría que pasar es que mi IDE favorito que implemente esta funcionalidad pudiera ser configurable para mostrar las regions de entrada abiertas en lugar de cerradas. Pero en ese caso, me reitero, ¿de qué sirven?
Entendedme, no es que esté en desacuerdo en que la gente pueda coger y ocultar la implementación de un método, viendo sólo su prototipado, para así ver la clase de una forma más global y general (si lo hace así con el resto de los métodos), pero ¿las regiones que puede escribir el propio programador de que sirven? Sirven, de hecho, para provocarle malos hábitos. De siempre es sabido que cuanto menos código tenga una clase o un método, más intuitivo y mejor escrito y modular es un código, ¿y cuando son útiles las regions? ¡Cuando el código es completamente farragoso, largo y poco estructurado! (aka spaghetti code).
¿Y poder ocultar la implentación de una clase entera? También lo veo inútil, porque yo tiendo a escribir una clase por fichero (aunque C# soporte varias, me gusta la rigidez de Java en ese sentido), cosa que parece más fácil de entender de cara a programadores que en el futuro tengan que entender tu código.
Conclusión: el único "ocultamiento" de código que me gustaría, sería aquel que pudiera alternar entre (a) Ver el código tal cual, (b) Ver sólo los prototipos de tus métodos de tu clase.
PD: Muchas gracias a todos los amigos y lectores de mi blog que me han animado a continuarlo. No es que hubiera querido dejar de escribir, sino que estos meses me ha resultado imposible sacar tiempo para escribir en él (a pesar de tener muchos artículos casi listos para publicar, pero aún en modo borrador), por cuestiones de intenso (aunque motivador) trabajo y de mudanza. De todos modos, sí he escrito alguna que otra actualización a entradas ya existentes, cosa que sólo se puede dar uno cuenta fácilmente si utiliza la suscripción RSS.
Actualización 05-JUL-2007: Resulta que hoy he encontrado otro inconveniente en esto del Code Folding junto con un compañero de trabajo. ¡Un bug de VStudio al buscar texto con el editor de VB.NET! Si la region no estaba abierta, VStudio engañaba al usuario diciéndole que el texto no se podía encontrar.
Labels: CSharp, General, Mono, Programacion
# posted by knocte @ 3:00 pm 
Comments:
<< Home
Personalmente el folding me parece muy útil. Por ejemplo, en el caso en el que vayas a ver código de una clase que no es tuya, con 1000 líneas de código, resulta muy útil compactar todo a definiciones para ver a vista de pájaro lo que hay.
Otro caso: estoy trabajando con dos funciones en el mismo fichero, pero no las tengo continuas. Colapso las que están en medio y tengo acceso rápido de una a otra.
Otro caso: estoy trabajando con dos funciones en el mismo fichero, pero no las tengo continuas. Colapso las que están en medio y tengo acceso rápido de una a otra.
Yo estoy con knocte, es bueno al para colapsar a nivel de definiciones (para ver sólo las interfaces de cada método) pero si dentro del código del método hay una región es un claro indicio de falta de refactorización sin duda, como todo, es una buena herramienta de la que se suele abusar.
Yo tampoco veo mal que se puedan ocultar los métodos o incluso el contenido de un if.
Como bien dices lo ideal sería no utilizarlo porque que el código fuese muy claro y estructurado, con métodos realmente atómicos, pero en el mundo real te encuentras métodos con cientos de líneas.
Así que apuntame en los que quieren que sea opcional que yo si que le veo utilidad ;-)
Como bien dices lo ideal sería no utilizarlo porque que el código fuese muy claro y estructurado, con métodos realmente atómicos, pero en el mundo real te encuentras métodos con cientos de líneas.
Así que apuntame en los que quieren que sea opcional que yo si que le veo utilidad ;-)
# posted by 
: Monday, July 02, 2007 4:47:00 pm
: Monday, July 02, 2007 4:47:00 pm
Un voto de confianza para el Visual Studio. Me gusta poder agrupar en una clase los métodos, propiedades y atributos para ver sólo lo que quiero ver en un momento.
Para gustos colores.
Para gustos colores.
Sobre el bug de VStudio al buscar en regiones colapsadas. En la ventana de buscar hay un check que permite buscar en texto oculto y que esta desmarcada por defecto. Así que no es un bug.
Yo también hecho de menos la agrupación de código en monodevelop.
Post a Comment
Yo también hecho de menos la agrupación de código en monodevelop.
<< Home
