Portada
mis comunidades
otras secciones
#1:
Me quedo con el "Diógenes" porque admito que lo hago muy a menudo. Si un trozo de código deja de ser útil, pero funciona, ¿quién es el insensible que puede borrarlo sin más? Personalmente yo soy incapaz, lo que hago es dejarlo comentado.
Y mi aportación a la lista de clases de comentarios chungos sería el "comentario desactualizado", que es cuando tienes un código con un comentario que explica lo que hace, llega un cambio contra-reloj (para variar) y modificas el código pero no el comentario. En el futuro cuando alguien lea ese comentario le costará entender por quécojones describe un proceso que no es lo que realmente se hace.
Y mi aportación a la lista de clases de comentarios chungos sería el "comentario desactualizado", que es cuando tienes un código con un comentario que explica lo que hace, llega un cambio contra-reloj (para variar) y modificas el código pero no el comentario. En el futuro cuando alguien lea ese comentario le costará entender por qué
#66:
Le ha faltado el "Uff, que a gusto me he quedao"
Ejemplo: comentario de Xee, visor de imágenes para MacOS. Atentos, oro puro:
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that these particular chunks should be aligned to four bytes, and that this alignement
// should not be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.
Ejemplo: comentario de Xee, visor de imágenes para MacOS. Atentos, oro puro:
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that these particular chunks should be aligned to four bytes, and that this alignement
// should not be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.
#18:
Yo me he encontrado comentarios tipo "no puedes pasar!!" con ascii de Gandalf incluido y otros del estilo, "XXXX es subnormal, mal programador y la tiene pequeña por esta mierda de código que NO FUNCIONA" o "Putas mierdas de GWT que no valen ni pa tomar por culo" o "Python es incapaz de hacer esto bien por eso he reimplementado su mierda de metodo", algunas en comentarios de GIT al subir un código, la de "XXXX como vuelvas a tocar esta funcion te corto las manos y la polla" están a la orden del dia
#52:
Esto es de una clase infumable que gestionaba una basura que no tenía remedio, cuando llegaba la parte en la que realmente estallaba el nivel de horror...
#6:
Clean code. Fuera comentarios del codigo
Comentarios
Me quedo con el "Diógenes" porque admito que lo hago muy a menudo. Si un trozo de código deja de ser útil, pero funciona, ¿quién es el insensible que puede borrarlo sin más? Personalmente yo soy incapaz, lo que hago es dejarlo comentado.
Y mi aportación a la lista de clases de comentarios chungos sería el "comentario desactualizado", que es cuando tienes un código con un comentario que explica lo que hace, llega un cambio contra-reloj (para variar) y modificas el código pero no el comentario. En el futuro cuando alguien lea ese comentario le costará entender por qué
cojonesdescribe un proceso que no es lo que realmente se hace.#1
Sería el comentario Legacy ...
#0 ¡gracias por el meneo!
#1 ¡somos developers pro-vida!
#1 #4 Yo las partes que no se usan si son muy grandes las borro del código pero las guardo en un fichero de texto que tengo con snipets de código para reutilizar.
Pero vamos si son cinco o seis líneas acaban comentadas
#72 #64 #23 preguntad a Enderwiggins en #4 es el autor
#73 #72 #64 #23 el problema de rellenado del botón back ya debería estar solucionado. Gracias por todo!
#1 Si un trozo de código deja de ser úti pero funciona, ¿quién es el insensible que puede borrarlo sin más? Personalmente yo soy incapaz, lo que hago es dejarlo comentado.
Si lo comentas es porque no es una función aislada (en ese caso la dejarías sin comentar) sinó que es es un cacho de código que está metido en un entorno a cuyos cambios es sensible. Pero no vas a mantener un código que está comentado. Entonces lo que pasa es que si llega el día en que quieres volver a usarlo no funciona porque el entorno ha cambiado y tardas lo mismo o más para adaptarlo al nuevo entorno (no recuerdas como estaba antes) que a volver a codificar esa funcionalidad de nuevo. Sí tiene sentido si crees que puedes necesitarlo a muy corto plazo. Pero esos fragmentos de código comentados que se perpetúan en la historia lo único que hacen es molestar.
#1 Es que nadie piensa en el control de versiones?
#1 Si, yo también soy muy de "Diógenes"... pero ya no por lástima, sino más bien por el exceso de competencia en las "altas esferas"/cliente, en plan: "Uy, asi no me gusta, mejor asao" y al mes de cambiarlo... "Uy, es verdad, asi es peor... si, mejor como antes"
De tener que recordar que narices hiciste a descomentar cuatro líneas y comentar otras hay un paso
En una práctica de universidad teníamos que coger el código que nos proporcionaba un profesor (unas 3000 lineas) y hacerle unas cuantas modificaciones.
En un comentario estaba escrito algo como:
// El mierda profesor este me ha hecho hacer esta mierda para que luego ni se la lea.
// No os ralléis si el ejercicio no os sale, poner un printf que simule lo que debe de hacer y ya.
// Os aseguro que no lee una mierda, solo lo compila y mira el output.
Lo peor es que tenia razón.
#14 Pero para eso usas un repositorio de código que es mucho mas limpio hombre.
#21 Ya, sabía que me lo comentaríais... Y es que no me refiero a cambios del grueso del desarrollo (que también, pero para eso si se usa el repositorio), sino más bien a cambios puntuales dentro de la vida de un desarrollo. Y ahí si que es mejor Diógenes que el repositorio, ya que este irá actualizándose y desarrollándose, y quizás los cambios a revertir sean cuatro líneas.
#1 Yo tengo complejo de basurero. Si veo un trozo de código comentado, tardo menos de medio segundo en borrarlo, que para algo está el control de versiones.
#24 Se llama T.O.C. yo también lo tengo
#1 Ya lo han dicho otros usuarios, pero acostumbrate a que tienes un control de versiones detrás que te permite recuperarlo siempre. Ya verás como realmente el código queda mucho más limpio cuando quitas todos esos bloques comentados de código no usado.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2098331/order/1">#1 Me quedo con el "Diógenes" porque admito que lo hago muy a menudo. Si un trozo de código deja de ser útil, pero funciona, ¿quién es el insensible que puede borrarlo sin más? Personalmente yo soy incapaz, lo que hago es dejarlo comentado.
Yo también lo hago siempre, aunque fuera código incorrecto, que nunca se sabe...
Yo añado el comentario-línea, que es un comentario para separar partes del código pero no pone ninguna letra. Yo lo uso mucho aunque lo borro al acabar:
#####################################################################
También está el comentario "ya comentaré más tarde que ahora mismo estoy enfilado" y que acaba siendo un simple símbolo de comentar.
Una variante del anterior es el comentario "recordatorio" que viene a decir algo así como.
#Explicar el bucle.
#1 Razones por las que es mejor borrar código que dejarlo comentado:
- El código borrado se queda en el sistema de control de versiones y puede ser devuelto a la vida.
- El código comentado normalmente no se refactoriza, por lo que si se vuelve a descomentar, lo más seguro es que haya errores.
- El código borrado hace el código más ilegible aniadiendo ruido.
Sé que a veces es duro deshacerse de código, porque ha costado mucho implementarlo. Pero si no sirve, no sirve. Debe ser tirado por la borda, es lo mejor para todos
#1 Joer, iba a poner eso mismo: el síndrome de Diógenes es mi retrato.
Para distinguirme de la aristocracia programadora que revolotea meneame, mi nivel de programador es de paria hacia abajo. Por si alguien está haciendo estadísticas.
Yo me he encontrado comentarios tipo "no puedes pasar!!" con ascii de Gandalf incluido y otros del estilo, "XXXX es subnormal, mal programador y la tiene pequeña por esta mierda de código que NO FUNCIONA" o "Putas mierdas de GWT que no valen ni pa tomar por culo" o "Python es incapaz de hacer esto bien por eso he reimplementado su mierda de metodo", algunas en comentarios de GIT al subir un código, la de "XXXX como vuelvas a tocar esta funcion te corto las manos y la polla" están a la orden del dia
Clean code. Fuera comentarios del codigo
#6 O usar COBOL, que se comenta sólo
Muy relacionado: http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered
#30 uno de los comentarios:
stop(); // Hammertime!
Le ha faltado el "Uff, que a gusto me he quedao"
Ejemplo: comentario de Xee, visor de imágenes para MacOS. Atentos, oro puro:
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that these particular chunks should be aligned to four bytes, and that this alignement
// should not be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.
Esto es de una clase infumable que gestionaba una basura que no tenía remedio, cuando llegaba la parte en la que realmente estallaba el nivel de horror...
No os habéis encontrado el típico "pendiente de mejorar" o algo por el estilo, incluso me he encontrado alguno con fecha para saber que lleva años "pendiente de mejorar" jejeje
#7 el TODO: es demasiado típico y normal. Es necesario en casi cualquier funcion que hagas rapidita, a menos que tengas 40 años programando y programes lento pero seguro. Pero los chupasangres no quieren a un lento que programe bien.
¿Alguien ha encontrado un "vendo Opel corsa" o "Ola K ase?" entre el código? Modo comentario Cani off
#2 De vez en cuando se me ha olvidado retirar de mi código algún print("OLA K ASE") de prueba.
Mis companieros son alemanes y no entienden mis mensajes "ocultos" y a veces los escucho confundidos leyéndolos en voz alta con acento aleman.
"OOLAH KA AAASEH? Was zum Teufel!?"
#17 echo("PEDO") dos anos en produccion, me envio un mail mi jefe para contarmelo y echarse unas risas, hacia casi un un ano que me habia ido de la empresa. Era bastante visible, casualidad que el cliente no se diera cuenta de eso durante tanto tiempo, lo descubrio el departamento de calidad
#17 traceln("que pasa co");
Menos mal lo que comentas... tengo también compañeros alemanes
#17 1º de carrera. Fui al despacho de mi profesor a preguntar una cosa. Comentario en un programa en ensamblador para ARM, de una cosa que no se me quedaba en la cabeaza:
)
; EOI == End of Interruption, COOOOOOÑOOOO!!
(Cuando me di cuenta de que no lo había quitado fue un "Tierra, trágame..."
SIempre cuento la anecdota ( de los 90) ; ORABLE iberica vendría una aplicacion de contabilidad hecha en forms y reportwritter 2.3 que tenia llamadas a PL/SQL y en el que habia un comentario de un propio programadoe de ORAGLE iberica que decia "la mierda del PL/SQL que nos han metido los putos yankis falla mas que su madre y no hay manera de que ejecute una subquery
Un comentario al fin y al cabo no es mas que expresar en lenguaje natural lo que no sabes expresar en el lenguaje de programación que estés usando. Normalmente es simplemente una cuestión de inexperiencia o falta de habilidad que se va corrigiendo con la practica, cada vez que tengas la intención de poner un comentario dedica un tiempo a pensar en como podrías expresarte mejor con tu lenguaje de programación para transmitir tus intenciones con la misma claridad en código fuente que con el comentario que queráis poner en lenguaje natural. A veces también te encuentras con limitaciones en el lenguaje o quizás con librerías de terceros mal diseñadas que te obligan a poner algún comentario explicando algo, pero son las menos veces y ese código siempre conviene encapsularlo en clases o métodos con buenos nombres. (poner buenos nombres es una de las más cosas más importantes y más difíciles de hacer en programación)
Y para los Diógenes, aprender a usar un sistema de control de versiones como dios manda y no seáis tan chapuzas. Código comentado = código borrado, sin preguntar, si no se esta ejecutando esta estorbando.
#40 Tienes razón en lo de Código comentado=Código Borrado... pero no siempre es tan fácil, al menos en mi caso generalmente ese código es código que he mejorado, o modificado,lo guardo por si el nuevo falla con la intención de borrarlo una vez acabe pero al final acaba quedandose comentado debido a que se me olvida borrarlo... o directamente me da pena eliminarlo, el pobrecico, por mucho que sea un engendro infecto y deforme salido del infierno, no merece ser ejecutado sin piedad, no soy partidario de la eugenesia!!!!1111
#43 Y para guardar distintas versiones del código (mejoras, modificaciones, locuras varias) no se será mejor un control de versiones... digo yo.
#40 No estoy de acuerdo. Un comentario bien hecho es resumir que hace un trozo de código junto con todas sus peculiaridades, para que cuando alguien que no seas tu tenga que usarlo no tenga que interpretar lo que has hecho, sino simplemente leer el resumen.
Los comentarios de código son la herramienta más importante para el trabajo en equipo. Confiar en que el que venga detrás entenderá a un simple golpe de vista tu código, es cuando menos irresponsable.
#51 Por lo general estoy de acuerdo contigo, los comentarios son muy útiles, eso sí, un buen código, muy bien estructurado, con funciones bien nombradas, variables bien nombradas y bien hecho, es casi un comentario en si mismo... pero eso es algo que no es lo habitual, lo normal es que el código sea una chapuza dificilmente legible.
#51 Lo irresponsable es escribir código que sólo se pueda entender con la ayuda de comentarios.
Lo importante es escribir código que otros puedan entender/extender/modificar, los comentarios sólo son un medio para conseguir este fin, decir que es "irresponsable no escribir comentarios" es confundir el fin con el medio. Existen mecanismo mucho más eficientes para escribir buen código que los comentarios, que realmente no son en absoluto en sistema fiable, tienden a quedarse obsoletos, son imprecisos por naturaleza, y más frecuentemente de lo que parece terminan haciendo el código más difícil de seguir que otra cosa.
Lo responsable es pararse y pensar un poco para elegir buenos nombres, es hacer un diseño que deje claro las responsabilidades de cada clase, es hacer test unitarios que expresen claramente cada funcionalidad etc,etc. (para más info, clean code es un buen libro para empezar).
#59 Lo que para ti es evidente, puede que para otro no lo sea.
Quizás en programas "sencillos" donde no existe algoritmia compleja se pueda prescindir totalmente de los comentarios haciendo uso de un código limpio, pero según mi experiencia, eso no siempre es posible.
#59 Te equivocas, en un entorno empresarial es irresponsable escribir código que no esté documentado.
* Primero, no todo el mundo entiende igual de bien las mismas cosas. Como bien indica #67 lo que para uno es claro para otro no lo es.
* Segundo, no puedes recomendarme cosas libros sobre código y luego argumentar que los comentarios se quedan desfasados. Un comentario desfasado es el resultado de una mala práctica de programación, exactamente que un código mal escrito.
* Tercero: un comentario permite que pueda utilizar tu código sin necesidad de entenderlo. En el mundo real, no hay tiempo para revisar todas las líneas de código, leerse todos los nombre de variable, ni realizar los test unitarios, de todos los trozos de código que tienes que utilizar a lo largo del día, es más, si tuviera que hacer eso, aun estaría con el primer proyecto en el que trabajé hace catorce años, revisándome los test unitarios del tomcat, xerces, xalan, jdk1.2, driver oracle, ... más el trabajo del resto de mis compañeros de proyecto.
* Cuarto: documentar el código es una obligación igual que lo es hacer un código limpio y bien diseñado. Una cosa vela por la usabilidad/reusabilidad del código y la otra por su mantenimiento.
#71 Es que siempre pensamos que los demás ven las cosas como nosotros, algo en lo que uno se termina fijando con el tiempo es que muchas veces el código representa formas concretas de pensar, y que tienen su lógica, pero si no las conoces parece que han tirado el código al azar, y se ha quedado tal cual.
#71 Oh dios mío, las aplicaciones "empresariales" y el "mundo real" atacan de nuevo. Todos sabemos como es ese mundo real, y precisamente porque se el tipo de código "empresarial" que se suele escribir te puedo asegurar que los comentarios no son la respuesta para conseguir construir sistemas mantenibles.
No termináis de entender que un comentario no es más que un mensaje escrito en un lenguaje (inglés, castellano) que quieres transmitir a quien lea ese código, el código fuente también esta escrito en un LENGUAJE, la gracia esta en aprender a usarlo para poder transmitir esos mismos mensajes en un lenguaje de programación sin necesidad de recurrir al lenguaje natural que es por definición menos preciso y que, como no se ejecuta y no se prueba, corre el riesgo de ser inexacto y quedarse desfasado.
Confundís el fin con el medio, el fin esta claro, escribir código mantenible, de lo que discutimos es de el mejor medio para lograr eso, nadie pone en duda que el código deba entenderlo cualquiera, la cuestión es cual es el mejor medio para lograr ese fin, y los comentarios no lo son. Confundes también documentar con escribir comentarios, hay muchas formas de documentación, evidentemente no necesitas leer el código de tomcat o xerces (por cierto jdk1.2... en serio?, esta cerca java 8...) para usarlo, pero también es evidente que esto no es gracias a los comentarios internos en ese código sino gracias a su documentación EXTERNA, tutoriales, ejemplos, documentación del api (javadoc en ese mundo empresarial javuno).
De todos modos, esta discusión es más vieja que el sol, hacer lo que os plazca, por si os interesa yo os dejo mi recomendación: cada vez que estéis a punto de escribir un comentario pensar dos veces si ese código no podría escribirse mejor y hacerlo entendible sin necesidad de dicho comentario. Si hacéis esto, poco a poco iréis mejorando vuestra capacidad de expresar ideas en un lenguaje de programación y creciendo como programadores.
#40 "poner buenos nombres es una de las más cosas más importantes y más difíciles de hacer en programación"
Amén a eso, lo peor es ver un código plagado de comentarios y explicaciones y que no se entienda porque las variables y los nombres de las funciones están excesivamente abreviados o son confusos... Un buen nombre facilita la lectura y ahorra comentarios.
Uno de los comentarios más raros que he visto era uno que hablaba de no quitar el comentario, ya que el programa dejaba de funcionar y efectivamente, al quitar el comentario dejaba de funcionar... Es una aplicación antigua, en ASP 3.0, que ha pasado por decenas de manos (todos ellos becarios sin experiencia, algunos incluso sin conocimientos de programación), mal parida desde su nacimiento y que está a la espera de ser sustituida por algo que funcione y pueda ser mantenida. Es la típica aplicación por la que cruzas los dedos para que no salgan problemas y que no quieran hacer modificaciones.
#53 Te creo; en la facu en una práctica de redes hecha en Turbo Pascal, el típico send-receive, si quitábamos un comentario fallaba la sincronización y la cosa NO andaba, mira que ha llovido y a día de hoy sigo sin saber por qué...
Yo abuso del diógenes, generalmente suele ser código que he mejorado/modificado/exterminado de forma salvaje(esto ocurre poco, por suerte) y luego olvido/omito borrar... Y bueno, del homeopático(o lo que es lo mismo, inexistente)...
#10 Yo suelo comentar código en desuso pero después de un tiempo, si vuelvo a esa parte y veo que hace mucho que no hace falta lo voy limpiando. A no ser, claro, que le tenga algún "cariño especial", o sea que se trate algo especialmente complicado o ingenioso que me haya costado hacer.
Yo amo los:
/* TO-DO: Fix it */
Ya que habláis del tema, para quien le interese el software craftmanship, que debería ser cualquiera que apreciara esta profesión, en madrid tenemos un grupo de meetup (http://www.meetup.com/madswcraft/) en el que organizamos reuniones una vez al mes más o menos, todo el mundo es bienvenido porque unos de los valores principales del craftmanship es precisamente compartir el conocimiento. En barcelona también se están moviendo cosas respecto al tema, por el norte están los cracks de programania organizando sus katayunos y merendojos, incluso en españa existe bastante movimiento y bastante gente muy buena alrededor del tema.
Antes de prejuzgar las cosas por el nombre sin tener mucha idea de que van, os recomiendo que os acerqueis a estos grupos, lo peor que os puede ocurrir es que perdáis algunas horas, y lo que le ocurre a casi todo el mundo que viene, que descubráis nuevas formas de hacer las cosas y afrontar vuestro trabajo.
Una cosa curiosa es cuando la gente afirma que no "tiene tiempo para metodologías y chorradas", es decir, no tiene tiempo para hacer cosas que precisamente existen para ahorrarse tiempo, ser más productivos y producir con mayor calidad.
Cuando estás con un proyecto que has tenido que dejar a medias, por la urgencia de otro o por lo que sea, y tras un tiempo después: días, semanas e incluso varios meses, debe retomarse, entonces es una bendición que te molestases en escribir aquellas líneas de comentarios de aquel código sin finalizar. La de tiempo que me ha ahorrado esta tarea sin necesidad de repasar casi todo el código.
Es más, incluso antes de ponerte a implementar una funcionalidad que aunque esté documentada en fichero externo, y ya tengas en la cabeza como la vas a abordar, recomiendo en el fichero de código donde se comentan los cambios o vas a implementar, resumir el cambio/funcionalidad y las partes de código (clases...) implicadas, porque puede que mientras escribes estos comentarios puedes darte cuenta de que puedes hacerlo de otra forma mejor o incluso de que se han obviado detalles necesarios. Y si no es así, siempre te valdrá para el primer párrafo que he escrito, nunca se sabe.
#87 He trabajado más de 6 años en España como programador, y 4 en UK. Nunca he sido más productivo que en mi vida (todo gracias a que haya buena gestión y la gente esté contenta, entre otras cosas), así que no es tema de "tener tiempo".
El libro explica perfectamente qué hacer con ese tipo de cosas, chapter 8: "Boundaries"
#88 No va sobre eso el "artesanal", sino sobre estar orgulloso de tu código y poner "cariño" en él. Y te aseguro que el código resultante si sigues los métodos del libro es mucho más mantenible, limpio, testable, y usable, que si no lo sigues... Y para mí eso es "ingeniería". De hecho, creo que es uno de los mayores avances en convertir a la programación en ingeniería.
Todo se basa en una cosa: si una cosa no se puede probar automaticamente, no debería estar en el código.
Lo he contado alguna vez, asi qeu lo copio y pego de la primera vez qeu me lo encontré, allá por otoño de 2010: hablando del To-Do
"Dentro de una de las versiones de la librería Bluecove (no recuerdo si Bluecove o su versión de linux la Bluecove-gpl) para la conexión con dispositivos externos mediante Bluetooth sobre java, existía un método para autenticar la conexión desde el propio código, evitando que el usuario tuviera que hacerlo, reduciendo el mantenimiento, olvidándose uno de que se cambie la versión de los paquetes de Bluetooth en linux, etc etc, siempre qeu se mantuviera la librería incrustada y que el pin estuviera definido y no se cambiara. Con un javadoc bastante molón:
/**
*
* Sends an authentication request to a remote Bluetooth device. Non JSR-82,
* Return false if the stack does not support authentication.
*
* PUBLIC JSR-82 extension
*
*@param device
* Remote Device
*@param passkey
* A Personal Identification Number (PIN) to be used for device
* authentication.
*@return true if authentication is successful; otherwise
* false
*@throws IOException
* if there are error during authentication.
*/
public static boolean authenticate(RemoteDevice device, String passkey) throws IOException
Como agua de lluvia para todos los integrantes del proyecto.
Hasta que resulta que no funciona.
Y que no funciona y que no funciona. Qeu devuelve true pero no autentica.
¿Qué pasará? ¿Será algún problema de timeouts? Se prueba en diferents máquinas, diferentes versiones de Windows, Mac y Linux. Y sigue sin funcionar. ¡¡Pero si la librería lleva funcionando 4 años!! ¿Estarán rotos los cacharros de 3.000 euros? Miedo. Desesperación. 8 personas subiéndose por las paredes, dos en cada punta de España, el currito y el jefe.
Hasta que a alguien (el que escribe) se le ocurre mirar el código por dentro e ir método a método hasta encontrar (palabras exactas):
// TODO I'll code this in the morning. It's 2:30 am"
Escrito 7 años antes y sin volver a tocarlo.
Qeu sí, qeu el To-Do está muy bien, pero si documentas todo, escribes las llamadas, pero luego no implementas el To-Do y lo commiteas, estás jodiendo a mucha gente
#20 Yo lo que no entiendo es porque no funcionaba después de 4 años sí funcionando porque alguien se olvidó hace 7 de acabarlo O.o
#49 La versión de la librería era de hacía 4 años. Y todo el mundo decía que funcionaba. Pero nadie hacía uso de la autenticación automática por lo qeu parece ser. Y no, versiones más modernas no llevaban cambios en esa parte.
#20 Ese ejemplo es un poco siniestro... quizás esa noche salió de su trabajo y nunca llegó a su casa ni sus familias volvieron a saber de él... quizás vio algo que no debería haber visto en los comentarios de otros.
Yo sólo pongo los comentarios que me obligan. Si el código no se comenta solo es que está mal escrito (exceptuando las excepciones).
Solamente 1 vez en mi vida he puesto un comentario que me ha salido de dentro. El comentario decia algo asi:
"ESTE CODIGO ES UNA PUTA MIERDA"
* No es broma.
Aunque hay una obsesión en insistir en lo de los comentarios, también hay otra obsesión en insistir que el codigo debería ser auto-explicativo. A mi juicio decir algo así, sería como decir que el hardware no debería llevar documentación, debería ser autoexplicativo. Un edificio no debería tener planos, ni deberían haber etiquetas en cables, etc, todo debería ser autoexplicativo.
Si haces código que nunca necesita ser comentado, es que nunca has hecho nada que valga la pena explicar. Que no se me ofenda nadie, hay una serie de "reglas" y "dogmas" que se repiten siempre que un buen profesional debería saber cuando violar y que gana/pierde en cada caso.
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
Ahora que hay tantos programadores en la sala, ¿Por qué después de leer la noticia intento volver hacia atrás y tengo que darle cien veces? ¿Por qué esta página de sinergiasincontrol.blogspot.co.uk se recarga cada segundo?
Pues que viva el código comentado por todos los dioses. Y también aprecio cuando la gente escribe gilipolleces al estilo "EL QUE TE AVISA", que a veces es una buena manera de reírte un poco mientras estás programando.
También recuerdo que un cliente que en principio no iba a ver el código en su vida acabara teniéndolo, y la que se lió por las burradas que se decían en los comentarios (por suerte luego todos somos informáticos y se entiende). Desde entonces todo código que vaya a cliente sufre una búsqueda de palabras como "subnormal", "mierda", "comercial" y demás detalles que puedan ser un poco ofensivos.
Yo comento incluso para mí, que volver unos meses después sobre algo que he programado lo facilita muchísimo tener comentarios acerca de qué hacía cada cosa.
@overrated
Por cierto, otra polemica...
Comentáis en inglés o en español?
#61 Si sigues el principio de única responsabilidad (SRP), te acostumbras a ello, y practicas TDD, no es ninguna utopía, es una realidad. De hecho, TDD es para muchos el primer avance en el mundo de la programación desde hace décadas.
#68 En inglés por supuesto... Pero porque trabajo en UK
yo peco de síndrome de diógenes
Yo una vez me encontré un "Power to the white people"
Y luego están las clases que te encuentras con 1000 líneas y 900 de ellas comentadas sin saber por qué. #TrueStory
#94 yo creo que si ves una buena batería de test te haces una idea buena de como funciona un código o módulo
Todo comentario en código es señal de mal código. Un código con tests y refactorizado, amén de con buenos y descriptivos nombres de variables y métodos no necesita comentarios.
#27 ...dijo mientras cabalgaba su unicornio rosado.
#31 ¿Qué parte de mi comentario no te parece razonable, factible, o buena práctica?
#37 Me parece razonable y buena practica, pero no factible. Cualquiera que tenga cierta experiencia programando para consultoria sabe de lo que hablo cuando el tiempo aprieta y las decisiones vienen impuestas de hora en hora. Ademas, a lo mejor en lenguages modernos y hipster todo es superguay y comprensible, pero prueba a hacer esto en C o en un XSD.
De entrada, pensar que tu propio codigo es perfecto y autoexplicado es de una soberbia que solo un programador puede alcanzar. Pero nosotros trabajamos en equipos de 5, 10 o 20 personas, y si escribiendo una linea de comentario puedes evitarme perder 10 minutos entendiendo tu codigo, no seas cabron y hazlo.
#39 no estas de acuerdo conmigo o con #27?
#81 Vale, fail, cierto... Mi comentario #39 iba para #27 pero al ver tu respuesta te referencié a ti por error. De hecho no puedo estar más de acuerdo con lo que expones, que es básicamente con distintas palabras lo que decía yo en mi comentario.
No lo podría haber dicho mejor de hecho: todos aspiramos a que nuestro código sea autoexplicativo y... por más que nombremos genial variables, funciones/procedimientos/métodos, etc. siempre vas a tener que utilizar funciones de librería (tanto de las estándar del lenguaje como de otras que te vengan cedidas o heredes de otros desarrolladores). Y por muy buen criterio de nombrado que haya tenido quien las ha desarrollado, ya son varios criterios de nombrado (el tuyo y el de esas librerías), y no todo el mundo tiene que saberse todas las funciones, ni siquiera las estándar... Un comentario, como dices y como decía, aunque a veces pueda parecer tonto, se pone siempre que se crea que alguien que va a llegar detrás puede, en alguna circunstancia, necesitarlo. Porque vale que tampoco sería un gran problema muchas veces entender el código, pero si vas comentando por bloques lo que hace o comentando las líneas que puedan tener más dificultad para favorecer entenderlas en un golpe de vista puedes llegar a ahorrarle a la próxima persona un coste en tiempo y en esfuerzo brutal. Igual que esa persona te lo puede ahorrar a ti si también lo hace.
Yo, personalmente, si tengo que tocar el código de otra persona y al abrir el editor veo que no está comentado, ya me cago en todo porque me temo lo peor. De hecho tengo comprobado que el código poco comentado suele ser, en general, obra de malos programadores y chapuceros. Y soy muy dado a ayudar a compañeros de hecho (estudio informática), pero si me piden ayuda con un código la única forma que tienen de que me niegue es que me enseñen el código y esté mal formateado o sin comentarios, paso de ir descifrando código ajeno encima de que hago un favor.
#82 Mi punto es que el 99% del código se puede refactorizar y organizar de modo que tenga sentido sin comentarios. Y ese código será más mantenible y comprensible que un tocho comentado.
Nadie que yo sepa, hasta que lo has hecho tú en este momento, ha planteado la dicotomía entre código bien factorizado poco comentado y código muy comentado pero sin factorizar . Evidentemente comentar código no es razón ni motivo para no factorizarlo adecuadamente. La elección, pues, salvo chapuceros que lo hagan ya todo mal, es entre código bien factorizado y formateado sin comentar, y código igual de bien factorizado y formateado y además bien comentado.
#83 #85 Esto que yo comento no me lo he inventado yo, los fundamentos los describe muy bien Uncle Bob en su "Clean Code", piedra angular del movimiento "Software Craftmanship" (http://en.wikipedia.org/wiki/Software_craftsmanship). Muchos lo consideran el primer avance en el mundo de la programación en décadas... otros no
No sé cuán popular es este movimiento en España, pero en países anglosajones está adquiriendo mucha popularidad.
Repito lo que dije por arriba: si comentas tu código has de mantener el código y el comentario, y si uno evoluciona sin que evolucione el otro (error humano, y que no se puede someter a tests automatizados), el resultado es peor que el código no comentado: código con un comentario que se refiere a un código que ya no existe.
#86 Aquí hay que hacer el trabajo de dos, no tenemos tiempo para metodologías, ni para profundos debates a la hora del té con el monóculo puesto sobre paradigmas de movimientos de metodologías, ni esas "chorradas"
Ya que estamos, ¿cómo se soluciona siguiendo esa metología lo que te cuento: explicar código anti-intuitivo que te has visto forzado a meter por usar código de terceros?
#86 No conocía ni remotamente el movimiento, pero sólo su nombre ya me echa algo para atrás... "Artesanía de software"... Yo creo que los que estamos defendiendo los comentarios lo hacemos desde una perspectiva de Ingeniería de Software. El software "artesanal" (proyectos personales o con pocas personas en equipo de confianza, poco a poco, y normalmente sin seguir una metodología de análisis o diseño clara, por no ser tan necesaria al no requerir ese tipo de comunicación en el equipo y soler ser proyectos mucho más pequeños) es algo totalmente diferente. No podemos aspirar a crear grandes sistemas como proyectos artesanales, sería totalmente inviable y los costes y tiempos de producción serían inviablemente altos.
CC #85
#31 No estoy de acuerdo. Un código bien factorizado, formateado y con variables bien identificadas ayuda un mundo, pero a veces aún así hay cosas que no quedan claras e impolutas a un golpe de vista. Y si lo niegas es que no has tenido que tocar mucho código ajeno o tienes una suerte tremenda y sólo has tocado código maravillosamente hecho y sencillo. Hay que tener en cuenta que lo importante no es que se entienda, es que se entienda lo más rápido posible, y lo importante no es que el que lo ha hecho y el que estaba al lado lo entiendan, es que lo entienda cualquiera que llegue detrás. El tiempo que pueden ahorrar unos comentarios aclarando código sencillo por bloques, por muy sencillo que sea el código y poco necesarios que parezcan, al debuguear un código o al tener que modificarlo para añadirle cambios puede ser impresionante.
#39 cuando comentas has de mantener el código y el comentario. Actualizar uno si el otro cambia. Y todos sabemos que la gente cambia código pero le cuesta mas cambiar comentarios. Al final acabas con código complicado de entender junto con comentarios obsoletos que hacen que sea aun mas críptico.
Y claro que he visto código horrible. Comentado y sin comentar. Mi punto es que el 99% del código se puede refactorizar y organizar de modo que tenga sentido sin comentarios. Y ese código será más mantenible y comprensible que un tocho comentado.
#27 Estoy con #31, eso es en un mundo utópico. Y es utópico pensar que siempre vas a hacer código de calidad 100% entendible.
Es más, esa afirmación se la suelo escuchar a la gente que por sistema no comenta nada con esa excusa, aunque el código resultante sea una mierda llena de "magic numbers".
Desde mi punto de vista prefiero encontrarme con un comentario redundante a encontrarme con un trozo de código sin comentar, con variables i, j , x, y, z y que tengo que descifrar lo que hace.
#27 Yo suelo intentar que el codigo sea lo suficientemente entendible como para que no sea necesario poner comentarios. En cualquier caso, la filosofia que suelo usar es: "No comentes que hace el codigo, comenta por que lo haces". Claro esta, cuantas menos veces sea necesario mejor!
#27 Hay comentarios que siempre se deben poner, por muy bien que esté tu código, y es cuando tienes que hacer cosas anti-intuitivas por algún bug raro de alguna librería o cosas por el estilo.
#27 No veo por qué unos tests van a facilitar la comprensión del código. De cualquier modo, aparte de utilizar una nomenclatura clara y consistente, las cabeceras explicativas casi nunca sobran (es más, hacen que veas más rápidamente de qué va cada método). Luego están los casos de código con ideas felices o directamente guarradas, que al verlos te acuerdas de toda la estirpe de quien lo hizo y no lo comentó. ¡Siempre hay que pensar en los que vienen después! Así reduciríamos esos tiempos de pesadilla con el código mantenido.
#92 Clean code. Chapter 9: Unit tests. http://www.amazon.co.uk/gp/aw/d/B001GSTOAM/ref=mp_s_a_1_2?qid=1390651970&sr=8-2&pi=AC_SX110_SY165
Resumiendo
El código debe estar vivo y refactorizarse continuamente. Si no tienes tests refactorizar no es fácil o es incluso infactible. Los comentarios no se pueden testear. En los tests es donde muestras tu intención a la hora de escribir código y cómo se usa tu código. Los tests se convierten en tu documentación.
Try it!
#93 Bueno, lo que yo dije era que no veía cómo los tests ayudarían a comprender qué hace el código, o mejor dicho, cómo lo hace; cómo funciona por dentro. Un unit test confirmará que una funcionalidad concreta funciona como debe, pero al que hereda un código y ha de modificar o extender lo que hace en un punto dado, esto no le sirve de gran cosa *en sus primeras tomas de contacto*. Claramente estos tests son útiles para probar rápido que los cambios o refactorizaciones hechas no rompan nada; pero no es ése mi punto: yo me refiero a que alguien nuevo pueda entender más o menos fácilmente cómo funciona lo existente para poder cambiarlo de forma rápida, sin pasarse mucho tiempo indagando cómo funciona por dentro. Un test, creo yo, ayuda solo *una vez lo has entendido* y ya has invertido el tiempo.
¿Pero qué mierdas hace esta página con el historial?!?!!!
o el siempre democrático: "función hecha por fulanito" que luego siempre vamos llamando al que ha hecho cada una para que nos explique que [censored] hacen
[Maldito comentario, ¡queda alineado!]
/*
* do (some) stuff
*/
El "to do" graciosillo me ha matao.
Aprovecho para una confesión: Sí, a veces padezco de síndrome de diógenes de código.
¿Quién escribe código en el Word?
#78 Los reptilianos
falta el que las variables son en si mismas comentarios yo soy de los de abusadores variable semanticas
function deleteRecordFromPositionBeforeOf (int i)
...
...
return theRecordWasSucesfullyDeleted;
}
bueno no tan exagerado, o a veces si, pero leer mi codigo es como leer prosa
El diógenes y la nave del misterio los mejores
#33 A mi me gustó lo de "es culpa del comercial" (me siento identificado con ello) y lo del comentario homeopático
Diógenes, Diógenes, Diógenes!
Yo me he llegado a encontrar árboles de Navidad como cabecera de un fuente que se picó una Navidades anteriores.
los controles de versiones son un peligro para un jefe que no hace su trabajo. Un día puse un cometario del tipo chapuzaRapida en el que ponía resumiendo que había que acabar eso en un tiempo absurdamente corto. Como siempre ibamos igual (el jefe no hacía su trabajo y ahora entenderéis por qué) eso se quedó ahí cerca de 2 años, esa clase había evolucionado bastante y había mil cambios más... hechos por mil personas, ya estaba olvidado... hasta que un día me llama el jefe al despacho y me pregunta indignado por qué he puesto ese comentario. Es decir, había perdido la mañana buscando quién había puesto ese comentario que osaba siquiera a dudar de su gestión, remontándose al pasado. True story.
El ultimo que acabo de ver es un framework que mantenemos "Me cago en Guido Van Rossum, su puta madre y toda su estampa", llevo 5 minutos descojonandome, parece ser que el nivel de frustración fue muy alto
sinergiasincontrol / comics / 361 . gif
comics / 361 . gif
361 . gif
.gif