¿Son las líneas de código vacías un síntoma de mala calidad?
AbrahamEn este artículo Yegor Bugayenko argumenta que el tener una línea de código vacía dentro de un método de una clase es un "mal olor" en el código. Desde su punto de vista, el hecho de que los métodos deberían tener sólo una responsabilidad y por tanto ser muy cortos y todas sus líneas de código deberían estar relacionadas con esa responsabilidad hace que no tenga sentido el "dividir secciones" dentro de un método empleando esas líneas de código vacías.
En su post original ejemplifica esto con un método inicial que, claramente, está resolviendo dos problemas diferentes, método que después rompe en varios métodos. Si bien estoy de acuerdo en que la refactorizacion que él presenta del código lo mejora (aunque todavía podría mejorarse más ese código), No estoy de acuerdo que nunca tenga sentido dejar una línea en blanco en un método. Por ejemplo, a mí me gusta separar la declaración de las variables que voy a usar dentro del método, del código, y suelo hacer esto con una línea en blanco.
¿Creéis vosotros que las líneas vacías dentro de un método son síntoma de código de mala calidad? ¿Las usais a menudo?
Reader Comments (12)
Supongo que es mejor poner líneas en blanco que poner un montón de código apelotonado.
Yo normalmente uso métodos privados como indica el autor. Otras veces, si tengo varios bloques "lógicos" dentro de un método los separo con un comentario.
Dicho eso, tampoco haría una regla de tal recomendación. Lo importante es que el código sea sencillo y se lea bien. Para ello, a veces será mejor usar métodos privados y otras separar bloques visualmente.
Lo ideal es que un método sea breve, que se pueda ver completamente sin hacer scroll, que no tenga más de unas cuantas líneas. Se debe poder entender que hace con un rápido golpe de vista.
Normalmente, cuando hay lineas en blanco, son para separar varios bloques funcionales... y entonces, hay un claro indicio de que hay varias responsabilidades mezcladas que deberían dividirse en distintos métodos.
Casi siempre, las lineas en blanco son un indicio de que falta hacer refactory, pero soy bastante permisible con ellas. Es algo que está muuuuy abajo en la lista de prioridades, si no afecta a la legibilidad ni al mantenimiento.
Otro tonto con un blog sobre programación. Ni caso.
En lo personal.
Líneas en blanco de separación, entre secciones como puede ser de declaración de variables y un bloque de proceso.
Entre bloques/lotes de proceso dentro de la misma función.
Indentar correctamente el código, para que la funcionalidad sea fácilmente legible.
Agregar comentarios dentro del cuerpo de una función a manera de "ayuda memoria" para no perderse en la maraña de una condición / asignación compleja.
Utilizar métodos privados o clases abstractas para separar / segmentar la funcionalidad de una clase, no solo por segmentación de lotes, si no para agrupar las funciones por naturaleza.
Todo esto, son trucos o mañas, que cada uno aprende, sigue, cambia, y evoluciona con el tiempo. En virtud de facilitar el mantenimiento y del contexto (léase equipo de trabajo) con el que tenga que interactuar.
Tratar de "legislar " sobre estos temas , sin ser quien debe mantener ese código. Me suena más a un prejuicio que a un juicio de valor.
Razonando como el tal Yegor Bugayenko:
"A mí no me gusta el gazpacho / el bacalao / el queso." => "El gazpacho / el bacalao / el queso es una mierda"
Con un par, majete.
Estoy con Alex. Yo siempre dejo una linea en blanco entre la declaracion de variables que voy a usar en todo el metodo y otra antes del return final. ¿Lo hago mal? El espacio es gratis...
De hecho, y ya que estamos, tampoco estoy muy de acuerdo en eso de que un metodo se tiene ver sin hacer scroll. Yo he escrito un motor de inyeccion de dependencias y en un lugar tenia un switch para hacer una conversion segun cada tipo de argumento en Java. Java tiene unos cuantos tipos primitivos y algun otro que hay que tratar (String, Integer, Double...) por lo comunes que son. Entre el case, un comentario, la conversion, un poquito de espacio para que quedara bonito, lo poco que se hace antes del switch y lo poco que se hace despues... mas de una pantalla.
Las ideas generales estan bien, pero el software a veces es complicado. Lo que importa es ordenar bien, sangrar como es debido, no ser racano con el espacio y comentar todo y mas aun.
Ummmm, siempre que leo algo así me recuerda mi propia experiencia. En mi trabajo me toca revisar el código programado por otros, así que por temporadas me paso una gran parte del tiempo revisando código y sufriendo el llamado "code smell".
En sí misma no creo que una línea en blanco sea un síntoma de mala calidad (creo que el autor no dice esto directamente en su artículo).
Personalmente creo que en lugar de una línea en blanco sería de más ayuda un comentario (es más, un comentario sí es una métrica de calidad, otra cosa es la utilidad de dicha métrica), pero a veces una línea en blanco es autoexplicativa.
public int getContador() {}
¿Es esa línea en blanco un síntoma de mala calidad? Yo creo que no, no sería tan radical, para mí no es más que un modo de organizar el código del método, separando las variables del código. Además, la línea en blanco ni siquiera contará como métrica, ya que para contar las líneas de un código lo mejor es emplear la métrica NLOC.
Sin embargo, esa flexibilidad algunos la llevan al límite, separando múltiples líneas en blanco el código en un método, e incluso con decenas de líneas en blanco métodos en el código. No hay palabras en nuestro idioma para expresar de un modo políticamente correcto lo que esa práctica me parece...
A ver entendamos a que apunta. En POO (pura y dura), se supone que la clave es que un objeto colabore con otro a través del paso de mensajes. Donde el que lo recibe ejecutará el método apropiado.
Si un "proceso de negocio" cuando se automatiza en un sistena, se resuelve con 100 LOC, se resuelve con 100LOC. Podemos tener un método de 100LOC o 50 métodos de 2 LOC. Ambos casos son extremos tal vez. Y ámbos puede ser que presenten ventajas o desventajas.
Desde la perspectiva de la POO si mi "proceso de negocio" esta compuesto por 10 "subprocesos", y hay un cambio de reglas de negocio en uno (de nuevo la POO empieza a tener sentido cuando el sistema cambia, dado que un apropiado diseño OO reduce el costo e impacto, dado que la encapsulación oculta detalles) o cambio el único componente que contiene todo tendrá impacto. Y el cambio me produce impacto en un componente de 100LOC. (que además pueden tener seguramente menor cohesion y multiplicar caminos lógicos lo que dificulta el testing). En cambio con un diseño modular, donde tenga 20 componetnes de 5 LOC seguramente el cambio debería impactar en un método de 5 LOC. ( planteo esto como ejemplo).
La POO es sobre todo colaborar y delegar y en ese sentido en un método separar el área de declaración del área de implementación me parece bueno, porque hace al código más legible, y no rompe el principio de que un método debe tener una responsabilidad específica y delegar el resto.
Ahora cuando muchas veces dividimos el método en 3 bloques lógicos, al menos deberían ser métodos ( privados al menos porque seguramente desde el cliente de nuestra clase no queremos exponer la implementación interna pero si subdividir en componentes más pequeños la lógica para reducir el costo del cambio).
Pero de nuevo no hay reglas mágicas, todo tiene sentido según el objetivo que nos pongamos (mayor performance, mayor legibilidad, mas fácil de mantener, menor consumo de memoria, o "tiene que funcionar para dentro de una hora" ) son todos objetivos posibles cuyo código óptimo es totalmente distinto.
Saludos.
El codigo de DataNucleus contiene muchas lineas en blanco, para que el codigo sea mas facil leer. Significa que el codigo es malo? El ojo y el cerebro necesitan espacios para separar y absorber la informacion mejor. Hay estudios.
Ademas el stacktrace de codigo de este tio (con cada metodo "muy corto") tendrian que ser tan largas que alguien perderia las ganas de vivir buscando la causa. Siempre hay tontos con sus ideas ... :-)
No veo mi comentario anterior, insisto con un concepto, el problema no son las LOC en blanco.
El problema (o el mal olor, o sea indicio de que nuestro diseño OO podría ser mejor) radica en usar los espacios en blanco para separar bloques lógicos, en lugar de hacer llamadas a métodos. Esto implica disminuir la encapsulación.
Si cambia un bloque lógico según las reglas de negocio cambien, si en un método tengo varios bloques lógicos, el impacto es mayor que si fuese solo cambiar una llamada a un método.
¿Por que? porque muchas veces en nuestro código si tenemos 3 bloques en un método, las variables de método solemos compartirlas, y aumentamos la complejidad del código.
Un bad smell no es algo que necesariamente esté mal, pero si un indicio.
Saludos.
El tal Yegor Bugayenko no hace mas que aplicar una de las maximas de la comunicacion: genera polemica y obtendras visibilidad, visitas, links. Es la unica explicacion a tal mamarrachada.
Yo personalmente estoy hasta la polla de mamarrachos que dicen que su forma de hacer codigo mola, y el resto es mierda. Hay cosas que entendemos todos, que son objetivas, como hacer metodos de 1000 lineas y 40 ifs anidados.
Pero llevar las cosas al extremo de decir que una linea en blanco es KK? ala por ahi. Para mi un codigo sin lineas en blanco es una basura ilegible. ¿tengo que separar absolutamente todo en metodos privados? ¿Que para entender un metodo tengas que visitar otros 80 metodos de 4 lineas, algunos de ellos con nombres absurdos para describir una funcionalidad tan pequeña? En fin, este tio solo quiere generar un flame para tener visitas en su blog.
Como es de esperarse, las respuestas hablan del sentido común de la gente que si desarrolla para vivir y no, como dice Alex, otro tonto con un blog (de los que abundan en el interwebs hoy en día...). Las líneas en blanco en el código son, según yo, el equivalente de utilizar pausas al hablar, no solo son cuestión de estilo sino también de necesidad, para darle un mejor contexto a la información que se está tratando de comunicar. Después va a salir algún otro hipster desocupado a decir que no se usen comentarios sino solo emoticones, xD. Rogaría al staff hacer un mejor filtro de las cosas que se publican.