El uso de regions en C# apesta
El título de esta entrada es un poco sensacionalista, lo reconozco, pero es la forma que se me ha ocurrido para llamar la atención sobre algo que creo que es importante tener en cuenta cuando codificamos.
A lo largo de todos estos años de experiencia trabajando en .NET, he asumido diferentes cambios de hábito y transformaciones en el uso de diferentes lenguajes de programación como VB.NET y C#.
Supongo que formará parte de la propia tarea de mejora y aprendizaje (eso quiero pensar). O bien de que con la edad, uno se vuelve maniático (que también es posible).
Una de esas transformaciones o cambios de hábito tienen que ver con las regions.
Alguien debió pensar que era una excelente idea, y la verdad es que cuando lo enseñaron, muchos como yo lo vimos como a un amigo al que no ves desde hace tiempo y al cuál quieres dar un caluroso y largo abrazo.
En seguida aparecieron muchas entradas en Internet indicándonos que era muy buena idea usarlos, y poco a poco muchos empezamos a usarlo a «cholón«.
Yo fuí de esos seres humanos que las empezó a utilizar y a recomendar en guías internas de programación, y que al cabo de un tiempo y sin casi darse cuenta, le encataba usar regions y las tenía interiorizada de tal forma, que cuando veía código sin regions me parecía que algo no era correcto en ese código. Me había vuelto sin quererlo en un maníaco persecutorio de las regions.
Sí,… me ayudaban a agrupar y organizar el código en bloques.
Eso era y es completamente cierto, y realmente pensaba que era bueno y que lo que hacía estaba bien y era lo correcto.
Lo cierto es que retrospectivamente hablando, considero que no era malo del todo, pero a la vez que mi experiencia mejoraba con el paso del tiempo, poco a poco fuí notando que las regions me molestaban más que me ayudaban. Eran como la típica mosca que a las puertas de una tormenta de verano no para de fastidiarte la siesta.
De amarlo, al odio… y poco a poco las fuí aborreciendo y tomé la decisión de iniciar el camino de vuelta.
Me fuí acostumbrando a ir eliminando el uso de regions… poco a poco eso sí, porque su uso es adictivo hasta la médula, y necesitaba ir haciendo un camino de retorno controlado para no volverme loco y perder la cabeza al salir del trabajo para ponerme a matar a gente por la calle.
Así lo estuve haciendo a lo largo de un tiempo, usándolas únicamente cuando el contexto o circunstancias del proyecto lo consideraba como algo necesario u obligatorio, pero evitando su uso siempre que me fuera posible. Había incluso ocasiones en el que sin quererlo y por inercia utilizaba alguna y me preguntaba a mi propio yo «qué estaba haciendo». Había otras ocasiones en las que era obligado su uso pero yo lo «omitía» y luego alguien me venía recordando que tenía que usarlas y me hacía el despistadillo.
Pero con bastantes clases de terapia programadora, al final creo que logré desengancharme… porque ya no recuerdo ni cuando fue la última vez que dije «ciao regions«.
Ahora, cada vez que veo código que tiene regions, un escalofrío me recorre la espina dorsal y de primeras pienso que el código apesta. Que el árbol no me deja ver el bosque. Que el código me obliga a hacer más scroll de la cuenta y mi muñeca se puede resentir de estar arriba y abajo como un lagarto.
Yo quiero ver el código de un primer y rápido vistazo, y utilizar la tecla avanzar y retroceder página como mucho.
Quiero localizar visualmente cada bloque de código fácil y rápidamente.
No quiero expandir y contraer regions. No, eso no es ser muy productivo la verdad. Y la gente no lo sabe, pero por cada acción de expandir y contraer regions, se muere un gatito, y eso hay que evitarlo.
Las regions, lejos de ayudar me molestan.
Lejos de hacerme ser productivo me entorpece.
Cuando veo el código lleno de regions… veo código que huele mal… veo código que me hace sangrar los ojos,… veo código que… apesta (sí, lo he dicho varias veces y lo reitero para que no haya dudas).
Nota aclaratoria: al hablar de código que huele mal, no confundamos con el término code-smell que hace mención a un problema de diseño que incrementa potencialmente la problemática y la posibilidad de tener bugs. Aquí agumento como código que huele mal al hecho de que una región podría albergar métodos demasiado grandes o mal estructurados. Anidaríamos y ocultaríamos el código dentro de una región y «evitaríamos» y pasaríamos por alto con ello la refactorización del método por ejemplo.
Y ojo,… con todo esto, no hablo de la calidad de nuestro código ni cómo está estructurado el código en sí, sino sólo de agrupar el código en regions.
Pero las regions son un vicio, una adicción como decía antes.
Hay quienes están tan enganchados a las regions que se atreven a anidar código en regions dentro de otras regions (yo lo hacía y molaba mucho).
Y bueno… ya para nota es utilizar regions dentro de parte del código de un método por ejemplo. Vas escribiendo tu método, metes una region ahí dentro y continúas con tu método hasta que lo acabas. Esto ya formaría parte de un high level de las regions del cual yo he huído siempre incluso cuando las regions y yo teníamos un idilio amoroso, pero hay quién lo utiliza (no me lo estoy inventando). Aunque respeto todas las opiniones, esto es a mi modo de ver una aberración y un masoquismo parecido a la autoflagelación programacional. Si el que va a leer el código es un enemigo, entonces sí, no dudes en torturarle de esta forma, pero si eres tú el que vas a leer el código, tírate por un puente y no te hagas daño de esa forma.
Pero como siempre, hay casos opuestos. En el otro extremo, existen herramientas que se encargan de eliminar las regiones… sí sí, de eliminarlas sin piedad (muerte y destrucción). Podemos llegar a ese punto si queremos, pero como decía antes, ni tan bueno ni tan malo, todo con cierta mesura. Dependerá del proyecto, contexto, etc., pero siempre que podamos, deberíamos evitarlas.
Ahora bien, si no quiero usar regions pero quiero organizar mi código de alguna forma «legible» ¿cómo deberíamos escribir nuestro código?.
Como decía antes, depende del contexto y de las circunstancias del proyecto, equipo, guías de programación, etc., pero en mi opinión, debemos evitar usarlo siempre que podamos. Por lo que lo ideal entonces sería ser organizados. Fácil decirlo pero complicado llevarlo a cabo… aunque propongo algunas ideas que espero que ayuden.
En mi opinión, bastaría con adoptar algunas pautas de trabajo a la hora de codificar nuestro código como por ejemplo:
Nombrar las variables, métodos, etc., con nombres legibles que identifiquen claramente qué hacen o para qué sirven.
Declarar nuestro código aglutinando por tipos y ámbito, como constantes privadas y públicas, declaraciones privadas y públicas, propiedades privadas y públicas, constructores, métodos privados y públicos…
Ordenarlos de arriba a abajo a ser posible alfabéticamente,…
En resumen, unas normas de codificación muy sencillas de seguir, que no compliquen demasiado la tarea de programación, y sirva para ayudar a leer el código de un vistazo rápido evitando el uso de regions que no nos aporta nada a excepción de añadir «texto» al código que no tiene valor.
Recordad también, que tener clases demasiado largas tienen pinta de estar «sobre-ingenieradas» (el palabro me suena fatal, pero ahora mismo no me sale uno mejor), y son candidatas de ser refactorizadas.
En mi caso y por lo general, prefiero separar el código en bloques lo más uniformes posible, por tipo, alcance y alfabéticamente, evitando como veis el uso de regions siempre que sea posible.
Dicho todo esto,… ¿tú eres de esas personas que pueden vivir sin regions o las amas como yo lo hacía antes?.
Happy Coding!
7 Responsesso far
Reconozco que yo también las he usado y no puedo estar más de acuerdo cuando comentas que siguiendo algunas prácticas sencillas (nombre correctamente los métodos, juntarlos por tipo, …) se consigue lo mismo sin tanta ‘parafernalia’
En el trabajo soy el bicho raro porque también estoy en contra de los comentarios (de aquellos que no aportan nada). Siempre comento que nuestro código debería ser legible como un libro. No es facil.
Hola Víctor.
Gracias por comentar.
Estoy completamente de acuerdo con lo que comentas de que el código debería leerle «solo» y no necesitar de comentarios.
Es verdad que a veces no queda más remedio que agregar algún comentario para aclarar alguna cosa que no querermos que se de por supuesta o se pase por alto, pero el código debería leerse sin necesidad de comentarios.
Y las regions a mi modo de ver (y veo que compartimos el mismo punto de vista), molestan más que ayudan.
No es fácil llegar a este punto, desde luego, pero una vez que lo haces te das cuenta que hay un antes y un después.
Un saludo y gracias por aportar tu punto de vista. 🙂
Pues no estoy muy de acuerdo. Creo que las regiones son un gran invento. Pero es como todo, si se usa bien. Y la experiencia es la que te dice cual es la mejor forma de hacerlo.
Lo de ordenar el codigo alfabéticamente o por tipo de variables me produce sarpullidos. El codigo hay que agruparlo por funcionalidad. Tenemos un Visual Studio maravilloso que nos ayuda a buscar fácilmente cualquier función o método.
Lo de refactorizar es algo necesario, pero con cabeza. En ocasiones el sustituir una clase por una región, puede simplificar mucho el trabajo. Aunque como todo, es complicado ponerse de acuerdo cuando es mejor crear una clase nueva.
Hola Andrés.
Gracias por comentar.
La experiencia de cada uno es la que vale.
Si a tí te parece bien usar las regions, no hay que darle más vueltas. Sigue utilizándolas.
En mi experiencia, me molestan más que ayudan, pero como ves, no soy un talibán de esto se debe hacer de esta manera o de aquella otra porque lo diga yo.
Yo me baso en mi experiencia y tengo una opinión al respecto, y tú basándote en tu experiencia con regions tienes la tuya la cual respeto pero no comparto.
Respecto a lo que comentas de agrupar por funcionalidad lo entiendo perfectamente, pero si dentro de una clase tienes muchas funciones o métodos con funcionalidades agrupables de diferentes formas, creo que lo lógico sería quizás refactorizar ese código en clases diferentes.
Una clase debería tener lo justo y necesario, y si tienes que hacer de una clase inicial cuatro, haces cuatro, no hay problema alguno.
Yo lo veo así.
Y sí, lo de refactorizar siempre con cabeza, desde luego.
He visto programadores en proyectos que refactorizan porque creen que es correcto, pero lo hacen sin criterio, con lo que generan más caos que el que tenían previamente.
Así que sí, siempre con cabeza.
Y sí también en que es complicado.
Como decía Víctor en otro comentario más arriba y le contestaba, no es fácil, y tampoco voy a tratar de convencerte, pero si un día te acostumbras a «renegar» de las regions, llegarás (supongo) a la misma conclusión que he llegado yo.
Sin regions se vive mejor. Pero es mi opinión y no tengo que convencer a nadie. Cada uno tiene su idea al respecto y uses o no regions, lo importante es lo que no son las regions que es lo que compila y funciona. 🙂
Un saludo,
Jorge
Ya esta dicho mas arriba pero me gustaría resumirlo en una sola frase:
Cuando llegas al punto de que las regiones te facilitan la vida en algo es que tienes montado un chocho en el código que mas te vale refactorizarlo.
Region es lo mejor que hay.
Podes no usarlo si no queres
Es para cada uno como se organiza
Para el gusto los colores desde luego Alejandro. 🙂