Es el mayor acto de maldad que he visto jamás... ¡es un genio!
#6:
Yo una vez me encontré un comentario que más o menos decía así:
No recuerdo las palabras textuales, de esto hace un par de años por lo menos. Era la página web de una pequeña empresa española de desarrollo web. Incluso pensé en largarme de la mía y pedir trabajo en esta
#8:
// If this comment is removed the program will blow up
Pues yo una vez, programando en Java, tenía un comentario que según lo pusiese o lo quitase el programa cascaba o no. Así que lo dejé. Siempre he pensado en dos posibilidades:
- Bug en el compilador.
- La lié de una forma que todavía no he conseguido comprender
Edito: ¡eh, ahí sale otro tío al que le pasaba, también en Java! ¡Igual no estoy loco!
// sometimes I believe compiler ignores all my comments
#9:
#8 A mi también me ha pasado eso , pero en c++ y siempre lo considerare como un misterio sin resolver, chupate esa 4º milenio!
#43:
muy bueno, me he partido la polla bastante, y que me decis de:
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
#49:
#13 Mi lista de hazañas:
He programado en más de 20 lenguajes: SI
Follo regularmente: NO
Soy peludo: SI
Uso linux: SI
Me pajeo con Galadriel: NO
Me importa el karma: NO
Me meto por el culo el sable de Darth Vader 30 aniversario edición especial con estrías: NO
Hay algo más triste que un friki presumiendo de ser friki: SI
Me pagan por ser rarito: NO
#20:
#16 En C TRUE no es una palabra reservada, es una constante (por eso está en mayúsculas, creo que vale 1), puedes redefinirla si quieres.
En la universidad me encontré con un compañero con un error muy parecido en una práctica, en concreto era un sistema de ficheros en C. Como no tenía nada mejor que hacer me pegué dos días para encontrar el error. Después de analizar casi todo el código fuente me dió por analizar el binario. La conclusión fue que un overflow por una mala definición de una array en otro fichero sobreescribía el principio del binario. Supongo que por cuestiones de debug o algo similar el compilador guardaba cierta información sobre los comentarios o sobre las líneas del código. Esos bits de información adicional eran suficientes para evitar que el overflow sobrescribiera las funciones que venían debajo.
#2 hasta donde mis conocimientos de programación llegan, que se me supone informático aunque hace años que no tiro una línea de código, ese "define" debería cascar en tiempo de compilación, dado que no le puedes poner a una constante de nombre una palabra reservada como sería TRUE.
#20#21 en ese caso, FALSE tampoco es palabra reservada, ¿verdad? por tanto ¿qué tipo de #define está haciendo?
P.D. C (en cualquiera de sus "sabores") y yo nunca nos hemos llevado bien, he preferido otras cosas como caml, python o incluso java (no por mucha diferencia este último... no por mucha... ), así que entre eso, y el tiempo que no pico código ya que ahora estoy en otras cosas, no recuerdo caso por caso cuál lenguaje usa cuál notación "case-sensitive" o no...
si saben tanto del codigo C para hacer pasar por entendidos, deben saber que en C e C++, lo preprocesador no entiende de palabras reservadas de C, es simplemente un substitutor de texto
Yo una vez me encontré un comentario que más o menos decía así:
No recuerdo las palabras textuales, de esto hace un par de años por lo menos. Era la página web de una pequeña empresa española de desarrollo web. Incluso pensé en largarme de la mía y pedir trabajo en esta
// If this comment is removed the program will blow up
Pues yo una vez, programando en Java, tenía un comentario que según lo pusiese o lo quitase el programa cascaba o no. Así que lo dejé. Siempre he pensado en dos posibilidades:
- Bug en el compilador.
- La lié de una forma que todavía no he conseguido comprender
Edito: ¡eh, ahí sale otro tío al que le pasaba, también en Java! ¡Igual no estoy loco!
#8#9#10#15#55 Las dos veces que me sucedió a mí eso se debía a caracteres "invisibles" provocados porque un desarrollador abría el fuente en formato UTF-8 y otro en ISO-8859-1 con distintos editores.
Al acertar casualmente a comentar una línea en la que estaba el carácter maldito, todo funcionaba. No digo que sea vuestro caso, pero nosotros tuvimos la suerte de dar con una causa plausible y no empezar a "emparanoiarnos"
En la universidad me encontré con un compañero con un error muy parecido en una práctica, en concreto era un sistema de ficheros en C. Como no tenía nada mejor que hacer me pegué dos días para encontrar el error. Después de analizar casi todo el código fuente me dió por analizar el binario. La conclusión fue que un overflow por una mala definición de una array en otro fichero sobreescribía el principio del binario. Supongo que por cuestiones de debug o algo similar el compilador guardaba cierta información sobre los comentarios o sobre las líneas del código. Esos bits de información adicional eran suficientes para evitar que el overflow sobrescribiera las funciones que venían debajo.
#8#9#10 Lo de los comentarios y los printf a mí también me ha pasado.
Ahora mismo no os puedo dar la explicación detallada (tendría que pensarlo durante un buen rato), pero el origen del problema suele ser el uso de una zona de memoria sin inicializar correctamente. Es decir, haces un malloc, y usas ese nuevo espacio para algo (directa o indirectamente, pasándolo como parámetro a otra función) sin haberlo inicializado antes (puesto a 0 con un bzero, o lo que sea).
#8 A mí me ha llegado a pasar en C++ con gcc. Añadiendo un cout con texto de control, para debuguear, el código funcionaba. Sin él, no. El caso es que ese cout me jodía el formato de salida
#5 Saber programar no tiene que ser sólo de frikis. De hecho, he programado en más de 20 lenguajes y follo regularmente, no soy peludo, no uso linux, no me pajeo con Galadriel, no me importa el karma y no me meto por el culo el sable de Darth Vader 30 aniversario edición especial con estrías. No hay nada más triste que un friki presumiendo de ser friki. Como si os pagaran por ser raritos.
#13 Radix, tus trolleos están perdiendo calidad. Creo que confundes freak con nerd. En cuanto a lo de follar, tiene que ser con otro ser humano y sin pagar, ¿eh?
#13 Mi lista de hazañas:
He programado en más de 20 lenguajes: SI
Follo regularmente: NO
Soy peludo: SI
Uso linux: SI
Me pajeo con Galadriel: NO
Me importa el karma: NO
Me meto por el culo el sable de Darth Vader 30 aniversario edición especial con estrías: NO
Hay algo más triste que un friki presumiendo de ser friki: SI
Me pagan por ser rarito: NO
#13 Cuando quieras hacemos una apuesta a ver quién folla más y otra a ver quién programa en más lenguajes y otra a ver a quién le cabe mejor la espada. Ayyyy... qué cosas hay que leer.
En el código de una aplicación de mi empresa, una de las variables era (desde tiempos inmemoriables):
Date cuandofulanitotenganovia = new Date(System.currentTimeMillis() + 100000000);
(Cámbiese fulanito por el nombre de una persona que de verdad trabajaba en mi empresa. Y sí, efectivamente, eran sólo 27 horas de espera para tener novia .).
#24
Me acabo de acordar de mis primeras prácticas en c++; en las que se instaba al usuario a que metiera un número, o otra cosa. Si por ejemplo pedía un número entre 1 y 10; y el usuario por joder ponía un 14; pues borraba el archivo de arranque de Windows y reiniciaba el equipo. (Primero, eso sí, llamaba gracioso al usuario y le dejaba tiempo para verlo).
return 1; # returns 1
Yo hacia cosas de estas cuando tenia horas bajas de creatividad, concretamente a partir de las 18:00.... Bendito horario iberico.
Saludos
En la librería Bluecove (una pila Bluetooth en Java o C bastante usada), hay el siguiente código (de memoria escribo) para lo qeu sería el apareamiento blueetooth entre el código (pc, móvil, etc) y el dispositivo al que queremos acceder por bluetooth.
public boolean authenticate (RemoteDevice device, string passkey)
Cuando trabajaba en una multinacional de videojuegos, alguien se encontró uno que decía "power to the white people" y lo publicó en los foros de discusión internos. Como resultado, los jefazos tuvieron que crear y distribuir un documento de normativa sobre los comentarios de código.
Aunque el titulo de la noticia discute sobre comentarios curiosos, etc. voy a ser la nota discordante; poner comentarios en codigo de alto nivel huele, habra que preguntarse porque un alto porcentaje de proyectos fracasan y siquiera pasan de las fases de diseno (y sino que se lo digan a los de Chrysler), los metodos convencionales se han impuesto por tradicion como si no pudiesen debatirse, cuando las metodologias agiles han demostrado tener un exito tremendo en grandes proyectos:
"Arguments rage over the importance of adding comments to your code versus the importance of writing clear code that speaks for itself, thereby potentially eliminating the need for comments. The dichotomy boils down to this: writing comments versus writing self-commenting code, as if comments and clear code are somehow mutually exclusive.
Before I get into the cut and thrust of this debate, it's worth stating that the subject of comments is less of an important issue than writing good code. While comments have value, if the code is crufty and convoluted, adding a few paragraphs of comments - while well intentioned - are only likely to add to the noise.
The Extreme Programming movement, back in its heyday, popularized the notion that comments in code are bad, taking the position that if you see a comment then it must be a "code smell" and you should grab your pair-programming buddy and refactor the stinky code immediately. The term used was "coding by intention" - writing code that so obviously communicates its method and purpose that it doesn't need to be commented."
Recomiendo la lectura de "Extreme programming explained", "The pragmatic programmer", asi como algunos libros como "Refactoring", a muchos nos ha ido mejor
#46 Ejemplos de metodologias agiles? extreme programming por ejemplo... o te refieres a ejemplos de codigo? en los libros que cite tienes muchos ejemplos de codigo (tambien en la noticia a la que hice referencia ponen alguno) puedes tambien seguir a Kent Beck y Martin Fowler. O si te refieres a ejemplos donde las metodologias tradicionales han fallado una y otra vez (en proyectos gigantes donde es mas critico todo esto) y donde ha tenido exito, tienes el caso que comentaba de la Chrysler, mas concretamente me referia a C3:
Responde esto a los ejemplos que pedias? o querias saber cosas concretas de metodologias agiles como CRC, crear los tests antes del propio programa? Parece incluso absurdo y poco posible si no lo has hecho nunca, pero luego te das cuenta que te ayuda por ejemplo a prototipar las clases:
#45 poner comentarios en codigo de alto nivel huele
estás diciendo que con métodos ágiles no es necesario comentar código?? Comentar código es algo que siempre es necesario, y más con métodologías ágiles en las que se hace menos énfasis en la documentación pura y dura
#51"Comentar código es algo que siempre es necesario, y más con métodologías ágiles en las que se hace menos énfasis en la documentación pura y dura"
No en metodologias agiles como XP (eXtreme Programming), lo de que siempre es necesario es una afirmacion dada en los metodos tradicionales generalmente (pero otras metodologias como XP como digo afirma lo contrario) asi que esa afirmacion es mas bien una opinion. Es mas en metodologias agiles como XP la documentacion es el propio codigo, que refactorizacion tras refactorizacion y empleando ciertos patrones de diseno para evitar estos comentarios al final permite crear algo parecido a un pseudocodigo en cuanto a la esencia del codigo se refiere. Cuando estude en la universidad mi codigo era el mas claro y no precisaba de comentarios porque empleaba estas tecnicas (en comparacion con el resto de clase) pero ademas es que no solo sirve para programas pequenos como en la universidad (y por eso hacia referencia a C3) de hecho yo mismo he empleado en varias de las empresas en las que he estado metodologias agiles sin comentarios en el codigo, pero he de reconocer que he usado comentarios cuando trabaje en codigo de bajo y medio nivel al desarrollar partes de un sistema operativo grande como es IOS (para otra empresa la que trabaje, Cisco systems). A lo que me refiero es que no se puede generalizar cuando empleas ciertos lenguajes para desarrollar alto o bajo nivel, ni por motivos como optimizacion (ya que yo estaba en el equipo de optimizacion de paquetes) el codigo es critico y predomina esa optimizacion sobre la legibilidad de codigo, es ahi donde si entiendo ciertos comentarios... pero no en programas donde la claridad es por culpa de malas practicas empleadas por el programador como el mal uso de la semantica por ejemplo.
#64 como bien expuse en #63 explico las razones de por que a veces es necesario comentar, pero comentar como lo hace la gente habitualmente es un error, simplemente recomiendo que leas el libro de "The Pragmatic programmer" (el que haya trabajado en alguna empresa con XP vera que no todo es utopia) simplemente la gente tiene ciertas costumbres y cree que porque es una costumbre no puede ser un mal habito, cuando en casi todos los casos lo es, excepto en contados... en mi caso cuando trabaje en esa empresa me tocaba revisar el codigo de IOS en busca de bugs, asi que no creo que sea yo al primero al que le interese perder legibilidad en el codigo me estaria echando piedras en mi propio tejado; simplemente digo que para programas o porciones de codigo 'no criticas' pruebes y apliques la teoria de dicho libro y me digas si funciona, es solo una sugerencia, si no te funciona podras comprobarlo luego.
Obviamente para escribir codigo claro se necesitan ciertas nociones y no todo el mundo es competente a la hora de desarrollar, asi que se necesita un tiempo y ver codigo de otros profesionales para darse cuenta que funciona (de ahi que recomendase otros libros en mis comentarios anteriores).
#67 "Mirando el historial del source safe vi que empezó recibiendo pero que a lo largo de unos 8 años, y tras pasar por 10 programadores, se le fueron añadiendo más datos a insertar en base de datos y nadie cayó en crear una clase que encapsulara todo."
Por eso mismo ciertas metodologias agiles recomiendan refactorizar siempre que puedas, no se puede mantener un codigo simplemente desarrollando sin refactorizar, es una practica de buenos habitos.
#68 Por eso día lo de talibán. Si programas elegantemente (métodos de pocas líneas y poco anidados, objetos que sólo hacen una cosa pero la hacen eficientemente, etc) apenas necesitas comentarios. Pero aun así siempre pongo el Javadoc (o equivalente) en todo lo que creo.
#70 Justamente de eso tambien habla XP, sobre los plazos que casi nunca se suelen cumplir empleando el metodo tradicional (a no ser que los programadores hagan muchas mas horas los ultimos dias para llegar a dicho plazo). Pero es mas, te contestare que eso en metodologias no agiles es mucho mas costoso por los ciclos del proyecto:
Lo digo porque a diferencia de otras metodologias, aqui si el proyecto fracasa o se queda a mitad por falta de presupuesto, etc. el cliente se queda con algo mas que un simple analisis o un analisis y un diseno, se queda con un programa funcional que cumple las funciones prioritarias y la falta de presupuesto hace que no cumpla las menos importantes (o no prioritarias). De todas formas yo no soy jefe de proyecto, pero mis jefes de proyecto no dan plazos imposibles, hablan con el cliente y de hecho el cliente envia a empleados suyos dentro de la empresa para ver el progreso del mismo (mas que nada para evitar sustos al final, eso tiene un nombre:
Ya os digo, podeis ver el ejemplo historico de C3 y vereis donde esas especificaciones que comentais cambiaban, que el sistema estaba en produccion, que era un monstruo enorme complejisimo de reformar y que el resto de metodologias fallaron aqui, pero no XP (y en la historia se explica cada detalle y como se soluciono), si no recuerdo mal, esto esta explicado en el "extreme programming explained".
#69 Es que si uno no hace el trabajo bien hecho es imposible trabajar con el en un mismo equipo, o cambia o se le cambia, no he visto autenticas barbarides por suerte porque esa gente o no entraba o ha cambiado.
#68, ese proyecto ya no hay quien lo refactorice, sería más rápido quemarlo y empezar de 0. A parte, el presupuesto es tal que el cliente te dice "Oye, ahora quiero guardar también el dato X, eso se hace en 5 minutos,no me lo cobráis, ¿no?
#45 No seas talibán (extremista). El día que un lenguaje de programación no necesite ser comentado, sencillamente no se podrá comentar. No conozco ningún lenguaje que no admita o ni siquiera que no aconseje comentar. O dicho de otro modo: si la definición de la gramática de un lenguaje incluye los comentarios, comentar es programar. Por tanto no omitas partes esenciales del código.
He trabajado con XP y algo con scrum y agradecí comentarios, sobre todo cuando alguno hacía código que era muy reusable. ¿Te imaginas usar las librerías estándar de C o de Java sin tener documentación? No es necesaria la biblia en verso, pero siempre se agradece que un comentario no te haga tener que presuponer nada.
PD: Programa siempre como si el que fuese a mantener tu código fuera un maníaco homicida que sabe donde vives.
Viendo la típica página de seriales, aparecia una ventanita superpuesta tapando la clave en la que te pedía que enviaras un sms. Viendo el html para apuntar la clave sin mandar el sms, justo encima de la clave:
#75 y #77 ¿Y habéis probado a explicárselo?
Lo digo porque mi chico lo hizo cuando le pregunté al respecto( frases cortas, concisas e inteligibles ) y así consiguió hacerme sentir menos lerda y, por consiguiente, mejor persona...
En uno: // Madrid = Hijos de puta (el absurdo motivo para poner esto era para indicar que las siguientes líneas de código indicaban que los PDF con origen en Madrid estaban corruptos, luego hubo que poner otro comentario para explicar el comentario )
En otra aplicación: //Esto no se para que sirve, pero que nadie lo quite, que si se borran las siguientes líneas teóricamente inútiles explotará la oficina
En la facultad, cierto profesor nos pidio una practica de un dia para otro, generalmente putearia, pero daria tiempo, ese dia NO.
Resultado, sin dormir consegui entregar la practica, comenzaba así:
/*Aqui empieza el codigo espaguetti, para saber como funciona, imprime el codigo, y coge celo y tijeras.*/
A continuacion el codigo, entero sin comentar y con una cantidad de GOTO brutal, diria que hecho a posta era imposible, pero estaba hecho a posta, y con mala leche.
Aprobe la practica, dado que el compilado funcionaba, pero el profesor me envio un email diciendo que si volvia a entregar una cosa similar, podia darme por suspenso mientras el fuese profesor
Una vez, yo estaba presentando un prototipo a un cliente, en una sala de reuniones llena de jefazos, con un proyector. El programa cascó y como lo estaba ejecutando desde el Visual Studio (mal hecho, lo se) apareció el código a la vista de todos. Y unas pocas líneas más abajo del fallo se leía:
On error resume next 'pongo esto para que no casque
Intenté cambiar de pantalla lo más rápido que pude, no se si alguien lo pudo leer, pero nadie dijo nada.
jajaja cuando mi novia me ha preguntado de qué me estaba partiendo, y le he contestado que de "los mejores comentarios en código fuente", uhm, os podeis imaginar...
p.d.: buenísimo el de "//Dear future me. Please forgive me. "
/**
*A las valientes almas que hayan llegado hasta aquí de lejos: Sois lso elegidos, los valientes *caballeros de la programación que trabajaron duro, sin descanso, arreglando nuestro códigop más *terrible. A vosotros, verdadores salvadores, reyes de los hombres, Yo os digo:
*never gonna give you up, never gonna let you down,
*never gonna run around and desert you. Never gonna make you cry,
*never gonna say goodbye. Never gonna tell a lie and hurt you.
/**
//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 25
//
long john; // silver
//Dear future me. Please forgive me.
//I can't even begin to express how sorry I am.
// somedev1 - 6/7/02 Adding temporary tracking of Login screen
// somedev2 - 5/22/07 Temporary my ass
/*
POO no solo es caca en inglés, es el acrónimo de Programación Orientada a Objetos.
Te recomiendo que leas algún manual básico de programación orientada a objetos porque no es normal que un método reciba ¡¡¡¡¡33!!!!! parámetros que se pueden encapsular en un objeto porque son datos de una misma entidad.
PD:
Encapsulación: (definición de encapsulación de la wikipedia)
Entidad: (definición de entidad de la wikipedia)
*/
Sí, un método que recibía 33 parámetros. Mirando el historial del source safe vi que empezó recibiendo 5 pero que a lo largo de unos 8 años, y tras pasar por 10 programadores, se le fueron añadiendo más parámetros a insertar en base de datos y nadie cayó en crear una clase que encapsulara todo.
En un trabajo que tuve me tocó depurar mucho código de FoxPro... y los comentarios eran absolutamente bestiales; por allí pasó más gente picando que por un burdel de carretera y cada uno hacía lo que le salía de los cojones..
Debo informar que acabo de descubrir quién es Galadriel y he de decir que me parece detestable que alguien se pajee con semejante personificación de la tristeza humana. Deberiais de intentar pajearos con seres más alegres y dicharacheros, con tetas rebotonas y culos meneantes.
Yo soy muy serio al poner comentarios pero cuando me da pereza no dudo en usar un truco: // self explainatory
Comentarios
#define TRUE FALSE //Happy debugging suckers
Es el mayor acto de maldad que he visto jamás... ¡es un genio!
#2 hasta donde mis conocimientos de programación llegan, que se me supone informático aunque hace años que no tiro una línea de código, ese "define" debería cascar en tiempo de compilación, dado que no le puedes poner a una constante de nombre una palabra reservada como sería TRUE.
Vamos, que sería una fantasmada del autor. Creo.
#16 En C TRUE no es una palabra reservada, es una constante (por eso está en mayúsculas, creo que vale 1), puedes redefinirla si quieres.
#20 #21 en ese caso, FALSE tampoco es palabra reservada, ¿verdad? por tanto ¿qué tipo de #define está haciendo?
P.D. C (en cualquiera de sus "sabores") y yo nunca nos hemos llevado bien, he preferido otras cosas como caml, python o incluso java (no por mucha diferencia este último... no por mucha... ), así que entre eso, y el tiempo que no pico código ya que ahora estoy en otras cosas, no recuerdo caso por caso cuál lenguaje usa cuál notación "case-sensitive" o no...
#16 #20 #21 #22
si saben tanto del codigo C para hacer pasar por entendidos, deben saber que en C e C++, lo preprocesador no entiende de palabras reservadas de C, es simplemente un substitutor de texto
#include
#define if while
int main()
return 0;
}
#30 http://i.imgur.com/9e0cI.png
#20 #21 de todos modos, un buen programador jamás hace una comparación con "true" o "false", y menos en C, que sería, si es necesario, con 1 ó 0.
#30 al contrario, si me has leído habrás visto que me he definido justo como lo contrario, listo, que eres un listo.
#16 TRUE != true (C++/>
En C++ true esta reserveda, TRUE no, daria un wraning en Windows, pues en windows.h esta el #define
#21 I win.
Yo una vez me encontré un comentario que más o menos decía así:
No recuerdo las palabras textuales, de esto hace un par de años por lo menos. Era la página web de una pequeña empresa española de desarrollo web. Incluso pensé en largarme de la mía y pedir trabajo en esta
// If this comment is removed the program will blow up
Pues yo una vez, programando en Java, tenía un comentario que según lo pusiese o lo quitase el programa cascaba o no. Así que lo dejé. Siempre he pensado en dos posibilidades:
- Bug en el compilador.
- La lié de una forma que todavía no he conseguido comprender
Edito: ¡eh, ahí sale otro tío al que le pasaba, también en Java! ¡Igual no estoy loco!
#8 A mi también me ha pasado eso , pero en c++ y siempre lo considerare como un misterio sin resolver, chupate esa 4º milenio!
#8 #9 Añadir otro a la lista. WTF total.
#8 #9 #10 #15 #55 Las dos veces que me sucedió a mí eso se debía a caracteres "invisibles" provocados porque un desarrollador abría el fuente en formato UTF-8 y otro en ISO-8859-1 con distintos editores.
Al acertar casualmente a comentar una línea en la que estaba el carácter maldito, todo funcionaba. No digo que sea vuestro caso, pero nosotros tuvimos la suerte de dar con una causa plausible y no empezar a "emparanoiarnos"
Para #8 #9 #10 y #15. Pues podeis estar seguros de que se trata de misterios con respuesta concisa.
#55 da algunas pistas interesantes.
#8 #9 #15 etc.
En la universidad me encontré con un compañero con un error muy parecido en una práctica, en concreto era un sistema de ficheros en C. Como no tenía nada mejor que hacer me pegué dos días para encontrar el error. Después de analizar casi todo el código fuente me dió por analizar el binario. La conclusión fue que un overflow por una mala definición de una array en otro fichero sobreescribía el principio del binario. Supongo que por cuestiones de debug o algo similar el compilador guardaba cierta información sobre los comentarios o sobre las líneas del código. Esos bits de información adicional eran suficientes para evitar que el overflow sobrescribiera las funciones que venían debajo.
#81 ¡La hostia! Sólo una pregunta: tú que las has probado, ¿las tetas de Trinity son de verdad o está operada?
#8 #9 #10 Lo de los comentarios y los printf a mí también me ha pasado.
Ahora mismo no os puedo dar la explicación detallada (tendría que pensarlo durante un buen rato), pero el origen del problema suele ser el uso de una zona de memoria sin inicializar correctamente. Es decir, haces un malloc, y usas ese nuevo espacio para algo (directa o indirectamente, pasándolo como parámetro a otra función) sin haberlo inicializado antes (puesto a 0 con un bzero, o lo que sea).
#8 A mí me ha llegado a pasar en C++ con gcc. Añadiendo un cout con texto de control, para debuguear, el código funcionaba. Sin él, no. El caso es que ese cout me jodía el formato de salida
#10 cout
Pues a mi me ha gustado este:
// sometimes I believe compiler ignores all my comments
//Atajo de frikis
for each (user in meneame)
//Desde el cariño de otro friki
#5 Saber programar no tiene que ser sólo de frikis. De hecho, he programado en más de 20 lenguajes y follo regularmente, no soy peludo, no uso linux, no me pajeo con Galadriel, no me importa el karma y no me meto por el culo el sable de Darth Vader 30 aniversario edición especial con estrías. No hay nada más triste que un friki presumiendo de ser friki. Como si os pagaran por ser raritos.
#13 Ya te digo, da vergüenza ajena.
#13 Radix, tus trolleos están perdiendo calidad. Creo que confundes freak con nerd. En cuanto a lo de follar, tiene que ser con otro ser humano y sin pagar, ¿eh?
#29 no te metas con #13 ¿no ves que está enfermito?
No te preocupes Radix, tener un nick de Dragon Ball ya no se considera friki.
#13 calla frikazo!
#35 berto-romero-lee-meneame....pero-no-entiende/0008
Berto Romero lee Menéame....pero no lo entiende......
lasexta.com#13 Te masturbas con Legolas?
#13 Mi lista de hazañas:
He programado en más de 20 lenguajes: SI
Follo regularmente: NO
Soy peludo: SI
Uso linux: SI
Me pajeo con Galadriel: NO
Me importa el karma: NO
Me meto por el culo el sable de Darth Vader 30 aniversario edición especial con estrías: NO
Hay algo más triste que un friki presumiendo de ser friki: SI
Me pagan por ser rarito: NO
#49 Déjame, que te enseño
Me pagan por ser rarito: sí, y me pagan una barbaridad.
#56 Pues sí, yo quiero ser rico, porque rarito si que soy. ¿Qué debo hacer?
#13 Cuando quieras hacemos una apuesta a ver quién folla más y otra a ver quién programa en más lenguajes y otra a ver a quién le cabe mejor la espada. Ayyyy... qué cosas hay que leer.
#13 por que hablas de darth vader?? frikazo!!!
#84 Unes Star Wars con GNU/Linux y sólo puede aparecer alguien como #13 diciéndonos esas cosas jajajaj
#5 que acaso meneame no era mainstream?
Y bueno, el mejor #comment es el primero *rickrolleado en el código*
muy bueno, me he partido la polla bastante, y que me decis de:
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
Vendo Opel C++orsa
En el código de una aplicación de mi empresa, una de las variables era (desde tiempos inmemoriables):
Date cuandofulanitotenganovia = new Date(System.currentTimeMillis() + 100000000);
(Cámbiese fulanito por el nombre de una persona que de verdad trabajaba en mi empresa. Y sí, efectivamente, eran sólo 27 horas de espera para tener novia .).
Lo de
//Magia. No tocar
también lo he visto.
Catch (Exception e)
Juro que me he visto tentado a poner alguno que otro de estos por el código de mi PFC.
// Replaces with spaces the braces in cases where braces in places cause stasis
Para muestra, un pincel, para que veáis lo bien que nos lo pasamos programando en jonéame:
if (!$_POST['cantidadOpciones']) die(); // a tomar x fly, por gilipuertas
foreach($encuestas as $id)
#24
Me acabo de acordar de mis primeras prácticas en c++; en las que se instaba al usuario a que metiera un número, o otra cosa. Si por ejemplo pedía un número entre 1 y 10; y el usuario por joder ponía un 14; pues borraba el archivo de arranque de Windows y reiniciaba el equipo. (Primero, eso sí, llamaba gracioso al usuario y le dejaba tiempo para verlo).
return 1; # returns 1
Yo hacia cosas de estas cuando tenia horas bajas de creatividad, concretamente a partir de las 18:00.... Bendito horario iberico.
Saludos
Desensamblado de un juego de Spectrum (Daley Thompson's Decathlon de Ocean)
0f8b STRING "(C) 1984 SpeedLock"
0f9d BYTE 0
0f9e STRING "Hey! Look Bill, another pirate tying to break our code, a thief son of thousand bitchs"
Auditando un código de 2006 en 2009:
// Acordarse de cambiarlo mañana.
En la librería Bluecove (una pila Bluetooth en Java o C bastante usada), hay el siguiente código (de memoria escribo) para lo qeu sería el apareamiento blueetooth entre el código (pc, móvil, etc) y el dispositivo al que queremos acceder por bluetooth.
public boolean authenticate (RemoteDevice device, string passkey)
fechado en 2003.
Cuando trabajaba en una multinacional de videojuegos, alguien se encontró uno que decía "power to the white people" y lo publicó en los foros de discusión internos. Como resultado, los jefazos tuvieron que crear y distribuir un documento de normativa sobre los comentarios de código.
#34 Algo similar que lo que hizo Microsoft:
http://en.wikipedia.org/wiki/Easter_eggs_in_Microsoft_products
Microsoft formally stopped including Easter eggs in its programs as part of its Trustworthy Computing Initiative in 2002.
Nunca te fíes de los comentarios:
/**
* Always returns true.
*/
public boolean isAvailable()
Para mi uno de los mejores es el primero de la 2ª página:
long long ago; /* in a galaxy far far away */
muy grande, jeje.
Aunque el titulo de la noticia discute sobre comentarios curiosos, etc. voy a ser la nota discordante; poner comentarios en codigo de alto nivel huele, habra que preguntarse porque un alto porcentaje de proyectos fracasan y siquiera pasan de las fases de diseno (y sino que se lo digan a los de Chrysler), los metodos convencionales se han impuesto por tradicion como si no pudiesen debatirse, cuando las metodologias agiles han demostrado tener un exito tremendo en grandes proyectos:
"Arguments rage over the importance of adding comments to your code versus the importance of writing clear code that speaks for itself, thereby potentially eliminating the need for comments. The dichotomy boils down to this: writing comments versus writing self-commenting code, as if comments and clear code are somehow mutually exclusive.
Before I get into the cut and thrust of this debate, it's worth stating that the subject of comments is less of an important issue than writing good code. While comments have value, if the code is crufty and convoluted, adding a few paragraphs of comments - while well intentioned - are only likely to add to the noise.
The Extreme Programming movement, back in its heyday, popularized the notion that comments in code are bad, taking the position that if you see a comment then it must be a "code smell" and you should grab your pair-programming buddy and refactor the stinky code immediately. The term used was "coding by intention" - writing code that so obviously communicates its method and purpose that it doesn't need to be commented."
Ref: http://www.theregister.co.uk/2008/03/18/code_comment_rows/
Recomiendo la lectura de "Extreme programming explained", "The pragmatic programmer", asi como algunos libros como "Refactoring", a muchos nos ha ido mejor
#45 "metodologías ágiles", que miedo me han dado estas palabras, podrías dar ejemplos?
#46 Ejemplos de metodologias agiles? extreme programming por ejemplo... o te refieres a ejemplos de codigo? en los libros que cite tienes muchos ejemplos de codigo (tambien en la noticia a la que hice referencia ponen alguno) puedes tambien seguir a Kent Beck y Martin Fowler. O si te refieres a ejemplos donde las metodologias tradicionales han fallado una y otra vez (en proyectos gigantes donde es mas critico todo esto) y donde ha tenido exito, tienes el caso que comentaba de la Chrysler, mas concretamente me referia a C3:
http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System
Si quieres ver un repaso general e introduccion sobre xP:
http://www.extremeprogramming.org/
Responde esto a los ejemplos que pedias? o querias saber cosas concretas de metodologias agiles como CRC, crear los tests antes del propio programa? Parece incluso absurdo y poco posible si no lo has hecho nunca, pero luego te das cuenta que te ayuda por ejemplo a prototipar las clases:
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/map/code.html
#45 poner comentarios en codigo de alto nivel huele
estás diciendo que con métodos ágiles no es necesario comentar código?? Comentar código es algo que siempre es necesario, y más con métodologías ágiles en las que se hace menos énfasis en la documentación pura y dura
#46 si te interesa saber más sobre métodos ágiles (yo creo que son el futuro) puedes leer Agile Software Development Methods de Pekka Abrahamsson, Outi Salo & Jussi Ronkainen
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.161.5931&rep=rep1&type=pdf
#51 "Comentar código es algo que siempre es necesario, y más con métodologías ágiles en las que se hace menos énfasis en la documentación pura y dura"
No en metodologias agiles como XP (eXtreme Programming), lo de que siempre es necesario es una afirmacion dada en los metodos tradicionales generalmente (pero otras metodologias como XP como digo afirma lo contrario) asi que esa afirmacion es mas bien una opinion. Es mas en metodologias agiles como XP la documentacion es el propio codigo, que refactorizacion tras refactorizacion y empleando ciertos patrones de diseno para evitar estos comentarios al final permite crear algo parecido a un pseudocodigo en cuanto a la esencia del codigo se refiere. Cuando estude en la universidad mi codigo era el mas claro y no precisaba de comentarios porque empleaba estas tecnicas (en comparacion con el resto de clase) pero ademas es que no solo sirve para programas pequenos como en la universidad (y por eso hacia referencia a C3) de hecho yo mismo he empleado en varias de las empresas en las que he estado metodologias agiles sin comentarios en el codigo, pero he de reconocer que he usado comentarios cuando trabaje en codigo de bajo y medio nivel al desarrollar partes de un sistema operativo grande como es IOS (para otra empresa la que trabaje, Cisco systems). A lo que me refiero es que no se puede generalizar cuando empleas ciertos lenguajes para desarrollar alto o bajo nivel, ni por motivos como optimizacion (ya que yo estaba en el equipo de optimizacion de paquetes) el codigo es critico y predomina esa optimizacion sobre la legibilidad de codigo, es ahi donde si entiendo ciertos comentarios... pero no en programas donde la claridad es por culpa de malas practicas empleadas por el programador como el mal uso de la semantica por ejemplo.
#64 como bien expuse en #63 explico las razones de por que a veces es necesario comentar, pero comentar como lo hace la gente habitualmente es un error, simplemente recomiendo que leas el libro de "The Pragmatic programmer" (el que haya trabajado en alguna empresa con XP vera que no todo es utopia) simplemente la gente tiene ciertas costumbres y cree que porque es una costumbre no puede ser un mal habito, cuando en casi todos los casos lo es, excepto en contados... en mi caso cuando trabaje en esa empresa me tocaba revisar el codigo de IOS en busca de bugs, asi que no creo que sea yo al primero al que le interese perder legibilidad en el codigo me estaria echando piedras en mi propio tejado; simplemente digo que para programas o porciones de codigo 'no criticas' pruebes y apliques la teoria de dicho libro y me digas si funciona, es solo una sugerencia, si no te funciona podras comprobarlo luego.
Obviamente para escribir codigo claro se necesitan ciertas nociones y no todo el mundo es competente a la hora de desarrollar, asi que se necesita un tiempo y ver codigo de otros profesionales para darse cuenta que funciona (de ahi que recomendase otros libros en mis comentarios anteriores).
#67 "Mirando el historial del source safe vi que empezó recibiendo pero que a lo largo de unos 8 años, y tras pasar por 10 programadores, se le fueron añadiendo más datos a insertar en base de datos y nadie cayó en crear una clase que encapsulara todo."
Por eso mismo ciertas metodologias agiles recomiendan refactorizar siempre que puedas, no se puede mantener un codigo simplemente desarrollando sin refactorizar, es una practica de buenos habitos.
#68 Por eso día lo de talibán. Si programas elegantemente (métodos de pocas líneas y poco anidados, objetos que sólo hacen una cosa pero la hacen eficientemente, etc) apenas necesitas comentarios. Pero aun así siempre pongo el Javadoc (o equivalente) en todo lo que creo.
#70 Justamente de eso tambien habla XP, sobre los plazos que casi nunca se suelen cumplir empleando el metodo tradicional (a no ser que los programadores hagan muchas mas horas los ultimos dias para llegar a dicho plazo). Pero es mas, te contestare que eso en metodologias no agiles es mucho mas costoso por los ciclos del proyecto:
http://www.agile-process.org/
Lo digo porque a diferencia de otras metodologias, aqui si el proyecto fracasa o se queda a mitad por falta de presupuesto, etc. el cliente se queda con algo mas que un simple analisis o un analisis y un diseno, se queda con un programa funcional que cumple las funciones prioritarias y la falta de presupuesto hace que no cumpla las menos importantes (o no prioritarias). De todas formas yo no soy jefe de proyecto, pero mis jefes de proyecto no dan plazos imposibles, hablan con el cliente y de hecho el cliente envia a empleados suyos dentro de la empresa para ver el progreso del mismo (mas que nada para evitar sustos al final, eso tiene un nombre:
http://www.agile-process.org/byfeature.html
http://www.agile-process.org/change.html
Ya os digo, podeis ver el ejemplo historico de C3 y vereis donde esas especificaciones que comentais cambiaban, que el sistema estaba en produccion, que era un monstruo enorme complejisimo de reformar y que el resto de metodologias fallaron aqui, pero no XP (y en la historia se explica cada detalle y como se soluciono), si no recuerdo mal, esto esta explicado en el "extreme programming explained".
#69 Es que si uno no hace el trabajo bien hecho es imposible trabajar con el en un mismo equipo, o cambia o se le cambia, no he visto autenticas barbarides por suerte porque esa gente o no entraba o ha cambiado.
#68, ese proyecto ya no hay quien lo refactorice, sería más rápido quemarlo y empezar de 0. A parte, el presupuesto es tal que el cliente te dice "Oye, ahora quiero guardar también el dato X, eso se hace en 5 minutos,no me lo cobráis, ¿no?
#45 No seas talibán (extremista). El día que un lenguaje de programación no necesite ser comentado, sencillamente no se podrá comentar. No conozco ningún lenguaje que no admita o ni siquiera que no aconseje comentar. O dicho de otro modo: si la definición de la gramática de un lenguaje incluye los comentarios, comentar es programar. Por tanto no omitas partes esenciales del código.
He trabajado con XP y algo con scrum y agradecí comentarios, sobre todo cuando alguno hacía código que era muy reusable. ¿Te imaginas usar las librerías estándar de C o de Java sin tener documentación? No es necesaria la biblia en verso, pero siempre se agradece que un comentario no te haga tener que presuponer nada.
PD: Programa siempre como si el que fuese a mantener tu código fuera un maníaco homicida que sabe donde vives.
double penetration; // ouch
#0 ¿Visto en http://joneame.net/historia/cual-mejor-comentario-codigo-fuente-jamas-hayas-encontrado por casualidad?
Muy grandes los de:
stop(); // Hammertime!
y
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
Viendo la típica página de seriales, aparecia una ventanita superpuesta tapando la clave en la que te pedía que enviaras un sms. Viendo el html para apuntar la clave sin mandar el sms, justo encima de la clave:
Exception up = new Exception("Something is really wrong.");
throw up; //ha ha
Por Dios que jartá a reir! A partir de ahora llamaré a todos los objetos Exception que cree up.
A continuación parte de un script en bash para reproducir la marcha imperial a través del altavoz del PC...
beep -f $SOL -l $NEGRA #TU
beep -f $SOL -l $NEGRA #TU
beep -f $SOL -l $NEGRA #TU
beep -f $MI -l $PUNTET #PUM-
beep -f $SI -l $MITJ #PU-
beep -f $SOL -l $NEGRA #RU
beep -f $MI -l $PUNTET #PUM-
beep -f $SI -l $MITJ #PU-
beep -f $SOL -l $BLANCA #RUUUU
beep -f $RE_ -l $NEGRA #PI
beep -f $RE_ -l $NEGRA #PI
beep -f $RE_ -l $NEGRA #PI
beep -f $MI_ -l $PUNTET #TI-
beep -f $SI -l $MITJ #TI
beep -f $FA1 -l $NEGRA #RII
beep -f $MI -l $PUNTET #PUM-
beep -f $SI -l $MITJ #PU
beep -f $SOL -l $BLANCA #RUUU
El script en ejecución aquí:
#75 y #77 ¿Y habéis probado a explicárselo?
Lo digo porque mi chico lo hizo cuando le pregunté al respecto( frases cortas, concisas e inteligibles ) y así consiguió hacerme sentir menos lerda y, por consiguiente, mejor persona...
#84 Estoy llorando de la risa!!!!
este me gusta porque me siento identificado
// I am not responsible of this code.
// They made me write it, against my will.
Huy, si vieráis las aplicaciones de mi empresa.
En uno: // Madrid = Hijos de puta (el absurdo motivo para poner esto era para indicar que las siguientes líneas de código indicaban que los PDF con origen en Madrid estaban corruptos, luego hubo que poner otro comentario para explicar el comentario )
En otra aplicación: //Esto no se para que sirve, pero que nadie lo quite, que si se borran las siguientes líneas teóricamente inútiles explotará la oficina
En la facultad, cierto profesor nos pidio una practica de un dia para otro, generalmente putearia, pero daria tiempo, ese dia NO.
Resultado, sin dormir consegui entregar la practica, comenzaba así:
/*Aqui empieza el codigo espaguetti, para saber como funciona, imprime el codigo, y coge celo y tijeras.*/
A continuacion el codigo, entero sin comentar y con una cantidad de GOTO brutal, diria que hecho a posta era imposible, pero estaba hecho a posta, y con mala leche.
Aprobe la practica, dado que el compilado funcionaba, pero el profesor me envio un email diciendo que si volvia a entregar una cosa similar, podia darme por suspenso mientras el fuese profesor
Una vez, yo estaba presentando un prototipo a un cliente, en una sala de reuniones llena de jefazos, con un proyector. El programa cascó y como lo estaba ejecutando desde el Visual Studio (mal hecho, lo se) apareció el código a la vista de todos. Y unas pocas líneas más abajo del fallo se leía:
On error resume next 'pongo esto para que no casque
Intenté cambiar de pantalla lo más rápido que pude, no se si alguien lo pudo leer, pero nadie dijo nada.
Pues varias veces:
// esto es una ñapa
...
...
...
try finally
// If this code work the author is : xxxxxxxxxxxxxxxx
jajaja cuando mi novia me ha preguntado de qué me estaba partiendo, y le he contestado que de "los mejores comentarios en código fuente", uhm, os podeis imaginar...
p.d.: buenísimo el de "//Dear future me. Please forgive me. "
#75 Me lo imagino: exactamente la misma cara que ha puesto mi mujer
Lo 2 primeros son los mejores...
/**
*A las valientes almas que hayan llegado hasta aquí de lejos: Sois lso elegidos, los valientes *caballeros de la programación que trabajaron duro, sin descanso, arreglando nuestro códigop más *terrible. A vosotros, verdadores salvadores, reyes de los hombres, Yo os digo:
*never gonna give you up, never gonna let you down,
*never gonna run around and desert you. Never gonna make you cry,
*never gonna say goodbye. Never gonna tell a lie and hurt you.
/**
/* The following code doesn't do anything */
A mí me han gustado estos:
// drunk, fix later
// Magic. Do not touch.
//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 25
//
long john; // silver
//Dear future me. Please forgive me.
//I can't even begin to express how sorry I am.
// somedev1 - 6/7/02 Adding temporary tracking of Login screen
// somedev2 - 5/22/07 Temporary my ass
Jajaja este ultimo es la leche.
El comentario de Pierre de Fermat es un clásico.
Los comentarios sobre el formato ADobe PSD ya salió
La frustracion sobre el formato PSD
La frustracion sobre el formato PSD
faq-mac.com>*Quien coño ha escrito esta mierda de bucle para filtrar???
>*Ah, joder, si fui yo!
En general el código de GStreamer es bastante gracioso con cosas como goto beach y comentarios muy ingeniosos.
/* Who frees this??? */
/*
POO no solo es caca en inglés, es el acrónimo de Programación Orientada a Objetos.
Te recomiendo que leas algún manual básico de programación orientada a objetos porque no es normal que un método reciba ¡¡¡¡¡33!!!!! parámetros que se pueden encapsular en un objeto porque son datos de una misma entidad.
PD:
Encapsulación: (definición de encapsulación de la wikipedia)
Entidad: (definición de entidad de la wikipedia)
*/
Sí, un método que recibía 33 parámetros. Mirando el historial del source safe vi que empezó recibiendo 5 pero que a lo largo de unos 8 años, y tras pasar por 10 programadores, se le fueron añadiendo más parámetros a insertar en base de datos y nadie cayó en crear una clase que encapsulara todo.
/**
* la palabra friki (o freaky, o como sea) esta sobrevalorada
*/
En un trabajo que tuve me tocó depurar mucho código de FoxPro... y los comentarios eran absolutamente bestiales; por allí pasó más gente picando que por un burdel de carretera y cada uno hacía lo que le salía de los cojones..
//Si estás leyendo esto sos un pobre infeliz
PASSWORDCAHYNA
Debo informar que acabo de descubrir quién es Galadriel y he de decir que me parece detestable que alguien se pajee con semejante personificación de la tristeza humana. Deberiais de intentar pajearos con seres más alegres y dicharacheros, con tetas rebotonas y culos meneantes.
Yo soy muy serio al poner comentarios pero cuando me da pereza no dudo en usar un truco: // self explainatory
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
Este me lo guardo para ponerlo yo