Hoy comparto dos videos que me encontré bastante curioso, ya que soy un fan de la ingeniería y programación de software.Se trata de poner un dispositivo especial que observa los movimientos oculares de personas (en este caso, de un programador novato y de un experimentado), y los grafico sobre el código de un programa. La idea es ver cómo rastrea el código el novato versus el experto, cuando a ambos se les asigna la misma tarea (que en este caso es descifrar cuál es el resultado de ejecutar el código que ven en pantalla).
Comentarios
Muy interesante y revelador. Esto es algo que no se enseña y de lo que no se habla mucho, pero gran parte del trabajo de un programador no es programar, sino comprender cómo funciona un código ya existente para corregirlo, ampliarlo o replicarlo.
Edito y aprovecho para reivindicar: ¡comentad vuestro código,
cabronesamigos programadores!#1
En España, al programador se le considera como que encaja piezas de un puzzle , sin esfuerzo analítico
¿ Que quieres que se haga algo ? Joder, pues con la funcion f_quiero_que_haga_lo_que_mi_jefe_quiere()
Y así los ven los jefes
#1 Y no escribáis basura de documentación autogenerada, como suele ser tradición en muchos lenguajes. La documentación se escribe en prosa y a mano.
Por ejemplo, muy buena documentación: http://docs.djangoproject.com/
#6 Lo de autogenerar es para mantener una estructura estándar (o lo más estándar posible) y encontrar rápidamente lo que buscas, algo tremendamente práctico cuando tratas con APIs de cientos de clases. Además permiten meter texto al programador para explicar aquello que no queda claro en el propio código (un código legible muchas veces es la mejor documentación)
#18 La documentación autogenerada está bien... pero no sirve de nada. Porque si quiero leerla, tengo el código fuente.
Lo que sí que está más claro que el agua es que afirmar que tienes documentación cuando esta es autogenerada es decir que no tienes documentación.
#1 #6 #12 #15 #19 #21 #22
Unas de las grandes peleas que siempre he tenido con programadores de código abierto es que no ponen ni un puñetero comentario. Megas y megas de código fuente donde los únicos comentarios son las cabeceras de la licencia GNU.
Cuando les pregunto simplemente te dicen que es bastante estúpido poner comentarios pues es escribir dos veces lo mismo y el código es lo suficientemente claro como para que cualquier experto lo entienda
Imaginaros el fuente de un programa de conversión de vídeo, o las tripas de un driver, o cualquier programa complejo.
Luego se preguntan por que hay tan poca gente que contribuya a sus programas.
#28 A ver, si un código es bueno es lee solo, lo que pasa es que cualquiera siempre piensa que su código es bueno, hay que ser más humildes al programar.
Por el nivel de comentarios en el código puedes saber si es bueno o no, cosas como "x++; // Agrego uno" es para matarlo y te dice claramente que te estas comiendo un código infumable.
#29 Recién sacado del código fuente del ffmpeg. Pues así está todo el proyecto:
static int convert_samples(DitherContext *c, int16_t **dst, float * const *src,
int channels, int nb_samples)
else if (state->noise_buf_size - state->noise_buf_ptr < aligned_samples)
if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) else
state->noise_buf_ptr += aligned_samples;
}
return 0;
}
Yo he llegado a pensar que la falta de comentarios es una forma de liberar el código y hacerlo libre pero al mismo tiempo hacer que sea inusable por los demás: Una forma de retener "derechos"...
#30 Algo rápido
// Función estática para corregir muestras¿
static int convert_samples(DitherContext *c, int16_t **dst, float * const *src,
int channels, int nb_samples)
// Si el metodo del contexto es triangular, le hacemos cosas
if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) else
// Suma y sige
state->noise_buf_ptr += aligned_samples;
}
return 0;
}
#32 Cachondo.... Eso ya lo se.
Los comentarios del código no deben explicar lo que hace el código: Eso ya se sabe leyéndolo. Deben explicar el por qué se hace lo que se hace. Y ahí es donde fallan todos.
#33
#34 Ves, #33 es un ejemplo de malos comentarios, normal que sacara un 0 en programación, no respeta el Espacio en el //, ya sabes que tipo de código fuente escribe
#35 No sabes lo que te puedes encontrar hasta que toca lidiar con el, eso te lleva a #15
#37 "no respeta el Espacio en el //"
+48691264
#49 espero que por lo de hacer códigos complicados no quieras decir que no se usen objetos o funciones para tareas autómatas. No vaya a ser que tengamos aquí un síndrome del espagueti consentido (SEC).
#50
Ejemplos de perlas que me he encontrado por ahí:
- Me creo un método dentro de un objeto, que llama a otro método dentro de otro objeto, que no hace nada salvo llamar a otro método dentro de otro objeto, que llama a otro.... y después de 6, 7, 8 niveles de llamadas... simplemente asigna un puñetero valor a una variable.
- Códigos espaguetti infernales, que repiten la misma acción n veces.
- Me creo una variable en la que, cada bit del contenido de esta, definira la escritura o no escritura, de un determinado fichero de log de la aplicación: [DEBUG][ERROR][WARNING] --> por tanto, 3 == 011, y esto hará que se escriban los logs de ERROR y WARNING, y evitará que se escriba el de debug. ¿No podíamos poner algo más inteligibleeeeee?
- Una web de 4 páginas (si, 4 posibilidades de acceso, nada más)... pero que está estructurada en 12 proyectos diferentes en visual studio, y con un código 10 veces mayor al realmente necesario.
Y ya no hablemos de aberraciones de las que hemos visto todos en el código alguna vez.
#53 Un buen programador, no solo es aquel que realiza un código eficiente, es el que es capáz de hacer un código limpio, claro, fácil de entender y de mantener.
#68 La eficiencia debería tener prioridad. Si por ser eficiente no se entiende, se comenta.
#57 Css != Programación
#56 Especialmente con los "#endif // CONSTANT_LOQUESEA" que pueden llegar a ser muy largos.
#75 como comprenderás yo de programación no tengo ni idea, como mucho algún script en LUA y casi siempre copiando y a base de prueba y error.
Lo del css lo decía por poner un ejemplo de algo inútil, en este caso lo inútil sería mi código css... me daría vergüenza que alguien lo viese, en serio, no me quiero imaginar la cara de alguien con conocimientos intentando averigüar por donde empezar.
#77 Todo se aprende
#28 Como programador de código abierto, tengo que darte la razón. Yo programo un driver de una librería y casi tengo más comentarios que código. Realmente, me habría gustado tener esa ayuda cuando empecé con ello. Como dice #34, no se trata de ir diciendo lo que hace el código, sino de porqué se hace así. Yo mismo no lo recordaría dentro de unos meses si no comentara en condiciones.
Hace poco se metió otra persona a colaborar conmigo y, aparte de porque es un crack, opino que ha metido mejoras bastante rápido porque me molesté en explicar porqué hacía lo que estaba haciendo.
#30 Pero si es muy fácil hombre, mira te lo comento en un pispas
static int convert_samples(DitherContext *c, int16_t **dst, float * const *src,
int channels, int nb_samples)
if (state->noise_buf_size < aligned_samples) { //Si la vecina del quinto está más buena que la del cuarto
ret = generate_dither_noise(c, state, nb_samples); //Echo el doble de lejía en el agua de fregar
if (ret < 0) //Si aún no ha terminado el telediario
return ret; //Pongo intereconomía
"> else if (state->noise_buf_size - state->noise_buf_ptr < aligned_samples)
if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) else
state->noise_buf_ptr += aligned_samples; // Despolariza todos los cofluxores.
}
return 0; //Devuelve la nota de mi examen de programación.
}
#33 dioooos me he estado riendo un ratazo largo y lo peor ha sido intentar explicárselo a mi madre >_
#30 Suele ocurrir que si el algoritmo es obvio (al menos para el que conozca el tema) se suele olvidar que la interacción con otros elementos del sistema no es obvia. ¿Por qué falla toda la función si fallo al generar el ruido para el dither? Un misterio, aceptémoslo con fe, hermanos.
#31 Yo estoy con #42, la documentación autogenerada sigue siendo documentación de código. Aún si es de buena calidad, sigue sin decirme nada del sistema. Compara http://docs.oracle.com/javase/7/docs/api/java/util/regex/MatchResult.html con http://docs.oracle.com/javase/tutorial/essential/regex/index.html. Sí, el segundo hace referencia al primero, pero leyendo el primero no he aprendido nada de expresiones regulares, ni soy capaz de usar esas clases para nada.
#55 Tú no quieres documentación, ¡tú lo que quieres es un tutorial!
Pues no me parece que el programador deba incluir tutoriales "desde cero hasta lo que haga falta" con todo código que libere. Si no sabes algo, aprende hasta que sepas... y cuando sepas, debería bastarte con leer la descripción de la función, nombres de las opciones, llamadas, etc.
Ej: nunca he usado regex en java, pero no tengo que leerme el tutorial para entender perfectamente esa documentación que enlazas.
#63 Creo que usé un mal ejemplo. Mira la documentación de regex de PHP http://se2.php.net/manual/en/function.ereg-replace.php, que además de la mera documentación de la interfaz, incluye ejemplos y aclaraciones. Eso no se puede generar a partir del código, y PHP lo solucionó agregando documentación de los usuarios.
#28 El codigo bueno se entiende solo.
Si lees un codigo que no entiendes, solo ha 2 opciones:
1. Eres muy novato.
2. El codigo es una mierda.
Caso 1: Necesitas emplear mas tiempo en escribir buen codigo. No escribas una mierda y luego la comentas.
Caso 2: Goto Caso 1.
#28 precisamente el otro día estuve revisando el código del gcc y me pasó lo que dices
#28 "Cuando les pregunto simplemente te dicen que es bastante estúpido poner comentarios pues es escribir dos veces lo mismo y el código es lo suficientemente claro como para que cualquier experto lo entienda"
Cambia lo marcado en negrita por: 'quiero que el menor número de gente posible entienda mi programa y, sobre todo, que el menor número de gente posible aprenda con él'.
Seguramente te acercarás más a la realidad de las cosas, por muy libre que sea su código.
#28 #46 Cuando gente que no tiene ni pajolera idea mete mano al código... suele ser mejor que no la hubiesen metido. Más de una regresión ha sido causada por gente que arreglando, o creyendo arreglar algo, la han armado bien gorda.
Especialmente vulnerables son:
- el rendimiento de algoritmos complejos (audio, vídeo, etc.) que no cuesta mucho bajarles el rendimiento 10 o 100 veces
- programas de seguridad (especialmente cifrado) que al mínimo descuido puedes dar al traste con todas las protecciones
#46 Lamentablemente, muchos programadores hacen los programas así... bajo el síndrome de autogeneración de imprescindibilidad (normalmente será gente tremendamente insegura acerca de sus capacidades).
#28 En el 95% de los casos, según mi experiencia, es cierto que los comentarios que ponen programadores con menos experiencia consisten en duplicar lo que dice el código y sobran. Y son altamente perniciosos, ya que no se mantienen, no dan problemas al compilar/ejecutar... y acabas viendo comentarios que dicen lo contrario de lo ves en el código en si.
#59 por eso no soy defensor de escribir comentarios en el código a no ser que sea estrictamente necesario. Soy partidario de escribir código auto documentado. Lección que insistía mi profesor de programación y la cual le tengo que dar la razón después de cinco años picando código y descifrando jeroglíficos de otros. variables con nombres entendibles, funciones con nombres descriptivos, métodos que hacen una única función (la que describe su nombre), etc. Mano de santo oiga!!!
#22 Si no sabes usar la documentación autogenerada es tu problema, yo la sé usar y va de coña. El truco está en escribir cosas tú. El autogenerador se limita a extraer los nombres de las clases y funciones, quien debe rellenar los huecos es el programador. Si el programador no pone nada, entonces la documentación autogenerada no sirve de nada.
Lo de mirar el código está muy bien, pero en muchos casos te pierdes navegando por el código fuente. El autogenerador te permite tenerlo todo limpio y ordenado, de forma que sea muy fácil buscar lo que quieres.
#31 Si en un proyecto solo encuentro documentación autogenerada, para mi ese proyecto no está documentado. Al igual que si no tiene tests, ese código no funciona.
“Code not tested is broken by design” - Jacob Kaplan-Moss
“Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce. About the only thing auto-generated documentation is good for is filling printed pages when contracts dictate delivery of a certain number of pages of documentation. I feel a particularly deep form of rage every time I click on a “documentation” link and see auto-generated documentation.” - Jacob Kaplan-Moss
Muy recomendable:
http://jacobian.org/writing/great-documentation/
#31 Yo me se de uno que no sabia si le iban a renovar, y se estaban portando mal con él.. Hacia su trabajo (programar), pero todo el código original lo dejaba sin comentar, por si le echaban de malas maneras...
#44 Pues les está dando una buena razón para echarle.
#1 Hay que comentar, pero comentar lo necesario y no poner comentarios del tipo
//empieza el if
if (...) //termina if
Esto es desesperante para un programador
#12
// Si i es igual a 1 entonces devolvemos true
if(i==1)
Todo un clásico. Luego están los que pecan de falta. Ver un código de 500 líneas sin comentar, que lo ejecutas y en algún momento aparece una ventana con el mensaje: "Error".
Hala, ahora búscate la vida jaja.
#19 hombre, es para que "quede mas estructurado el código"
#12 De hecho esos comentarios ni siquiera son de novato. Son de un profesor enseñando el lenguaje o de alguien que lo está aprendiendo y aún no se sabe la sintaxis (entiendo que novato es que ya tiene cierta experiencia, aunque poca).
Los únicos comentarios que ayudan en realidad son los que explican el por qué se hace algo que en principio no es obvio.
#12, si te encuentras un megacódigo, te aseguro que los comentarios de #fin IF lo que sea...
te resuelven muchas dudas y tiempo a primera vista (no en cambio el otro comentario obvio) pero sí estos comentarios de bucle. (a no ser que vayas con el p.e. notepad++ cerrando y abriendo estructuras con el (+) pero que es un engorro
#1 Así no se piden las cosas, ahí que ser mas contundente: "Programa siempre como si la persona que fuera a mantener tu código fuera un asesino en serie maníaco que sabe donde vives", después de Mcafee esta frase se ha revalorizado
#15 Y de Hans Reiser
#24 Oh, el buen Reiser... un sistema de archivos matador.
#15 Mi filosofía es programar y comentar de tal modo que el programador más tonto que va a tocar mi código lo pueda entender. Es bastante fácil porque el programador más tonto soy yo después de no haber dormido la noche de antes, y lo conozco bien
#15 Documenta el código como si lo tuviera que leer un analista de negocio (que sea un asesino en serie que sabe dónde vives se da por supuesto) ¡y entenderlo!
#1 los comentarios son innecesarios, la mejor documentación son test unitarios y funcionales claros y sencillos
#1 Otra reivindicación:
Alguien inteligente es quien es capaz de sacar una solución fácil un problema complicado y alguien estúpido es quien de algo fácil consigue convertirlo en algo complicado.
Estoy harto de ver códigos EXTREMADAMENTE COMPLICADOS para problemas tremendamente sencillos.
Por favor, hacer las cosas "más guays", no os hace mejores programadores, sin embargo... FASTIDIA TREMENDAMENTE, la vida de los demás.
En resúmen... opino que hay una máxima a seguir: La solución más fácil y más clara, a la larga, os creará mejor vida a vosotros y a todos vuestros compañeros.
#49 En mi opinion, no es cuestion de codigo mas complicado o menos complicado, sino mas EFICIENTE o menos EFICIENTE.
#1 Mucho mejor sería escribir código limpio [1].
Los comentarios también requieren mantenimiento, y pocas cosas hay más frustrantes que encontrarse un fragmento de código ofuscado con el comentario supuestamente explicativo desactualizado y que ya no corresponde con el código revisado.
[1] http://www.cleancoders.com/
Yo lo hago así: http://i.imgur.com/xVyoSl.jpg
#8 Oye canino, cuando quieras nos batimos en duelo.
Titular alternativo: "Cómo dos personas distintas leen un trozo de código". Cantidad de información extraible: 0
Me gustaría ver qué cambios se producen cuando hay resaltado de sintaxis.
Lo mismo que he puesto en la página, lo pongo aquí.
Para tener significancia como experimento científico, tanto novato como experto deberían haber trabajado sobre el mismo código. Si a cada uno le ponemos códigos diferentes estamos comparando churras con merinas.
Aún así, es curioso ver como el novato se dispersa mucho más por todo el código mientras que el experto es más analítico y se centra en una parte y la resuelve, y luego va a la siguiente.
#5 A mí también me habría gustado, me he quedado con las ganas de ver si algo cambiaría.
La prueba debería haberse realizado sobre cualquier IDE o entorno de desarrollo visual.
Cualquier tuercebotas te puede hacer un programa sin tener idea de código, con lo cual hubiera habido mas equidad en la prueba.
Estoy de acuerdo con #7 con respecto al seguimiento que hacen uno y otro con respecto al seguimiento del código.
¿Conocéis la unidad de medida de la calidad de un programa? El WTF por minuto: http://codinghorror.typepad.com/.a/6a0120a85dcdae970b012877707a45970c-pi
Yo diría: Programa después de diseñar, y diseña pensando en la mantenibilidad.
He visto cosas que vosotros no creeriais. Métodos de más de 2000 lineas, programadores vírgenes que no entienden los objetos, y programadores "expertos" que tampoco. Todo eso se queda ahí porque es código heredado y yo no lo toco ni bajo amenaza de muerte...
Voto errónea. Ni el código está estructurado de la misma forma ni se puede sacar ninguna conclusión. Además está mal resuelto. El titular me llama la atención, pero es errónea.
Errónea como una casa de grande. No están analizando el mismo código.
#39 goto #38
Yo soy mas de Cobol.
Eso que muchos dicen de que el buen código es su propia documentación está bien pero...
No siempre hqceis/hacemos buen código.
Para entenderlo hay que leerlo y eso conlleva más tiempo que leer una explicación, al principio, de lo que hace.
En resumen: No seais vagos ni penseis que sois la ostia.
http://coderfacts.com/post/18600518280
while(1)
Pues será muy experto, pero la caga.
#3 Pero la caga mejor.
Bromas aparte no veo muy cientifico que el programador novato se encuentre con una pieza perfecta de copy&paste y el experto con código estructurado. Erronea
#4 El tema es que si no pones el mismo código... pues como que el vídeo no tiene mucho sentido
No todos los expertos siguen la misma pauta mirando código ni tampoco todos los novatos. A parte, lo que dicen #4 y #9.
No solo me parece irrelevante (que entonces paso de menearla), sino que me parece sensacionalista (la voto como tal).
#4 En total hay 10 ejercicios. Si te fijas al final del vídeo del novato se ve que lleva resueltos los 7 primeros, al principio del del experto se ve como empieza a resolver el décimo y último. De ahí a votar errónea... ya que estás podrías votar errónea porque sólo han participado 2 personas y eso es un mal muestreo, ¿no? Evidentemente han elegido 2 videos que ilustran los resultados de entre los 10*N_participantes vídeos que tienen. Pero claro como no te han dado todos los resultados en bruto, pues no es científico. En fin, si tanto te preocupaba la rigurosidad del estudio podrías haber clicado en el enlace al mismo, para descubrir esta respuesta al primer comentario:
Experienced and novice programmers don’t always get different versions. I randomly assign participants to one of the two or three versions of each program. This should let me see which kinds of code difficulties are related to experience.
Lo de los comentarios es un mundo. Seré malvado pero opino que los comentarios sólo deberían:
- Explicar lo que no es evidente. Ejemplo: " Esto lo hago para evitar problemas de transacciónes.
- Igual que un libro, trozos de código pueden tener títulos.
Si no es así, generalmente es que el código no está bien. Por ejemplo:
int ch, ret; //Declaro variables para tiemnpo de cocción de fideos y diámetro cacerola
Los nombres de las variables no son intuitivos. En nuestro caso channel_counter sería más apropiado.
#70 Exacto.
El nombre de las variables, funciones, clases y objetos deben reflejar fielmente la entidad que representan de forma que el codigo escrito con esos nombres se parezca mucho al lenguaje natural.
Si con los nombres de funciones y variables no se puede explicar que representan o que tarea realizan, lo que ocurre en el 99.99% de los casos es que el codigo es incorrecto y esta pidiendo un refactor a gritos.
Cuando me encuentro un codigo que esta lleno de comentarios, lo primero que hago es santiguarme para que por adelantado se me perdone las veces que voy a tomar el nombre de Dios de vano.
El código es la documentación definitiva. Para bien y para mal.
Creo que el problema no está en novato vs. profesional. Diría que no es cuestión de conocimientos, sino de actitud. Claro que, cuanto más experiencia uno tiene, menos se deja llevar por la pereza (de otear en lugar de pararse a analizar) porque sabe que es contraproducente para sus resultados (ahí también cuenta el querer obtener unos resultados excelentes y no simplemente arreglar el problema). Y como nota, entiéndase por experiencia, el aprender de los errores o el intentar hacer lo mismo por distintos métodos, y no el haber pasado muchos años delante de la pantalla, que es algo que se suele confundir mucho.
Mi triste impresión, es que la calidad de la documentación es inversamente proporcional al tiempo de entrega. Muchas veces (y algunos me consideran "experto") me he maldecido a mi mismo por haber mal documentado un código que debía entregar "ahora, ya". Sobre la autodocumenración, si la aceptamos como válida, lo cual es discutible, depende mucho del lenguaje. Es muy diferente un programa en Asembler, a otro en Python. En el primer caso, por norma, si debo trabajar sobre un código no documentado, tardo menos volviendolo a hacer que intentando descifrarlo, con Python, es más excusable, pero insisto, no perdonable.
Los códigos son diferentes y el experto pone el resultado mal.
Un gran ejemplo de comentario en el código es:
//PEPITO
Y sí, Pepito ya no está en la empresa y no hay ni habrá forma de localizarle...
Interesante sí señor, aunque ya me gustaría ver al experto intentando analizar un simple código CSS hecho por mi... seguro que le entraba dolor de cabeza
Yo ya estoy muy oxidado, a ver si vuelvo a los cursos de Udacity. Programar mola con ellos.
El novato es novato novato, madre lo que le cuesta Yo me considero novato y me parezco más al experto. De hecho creo que es un código demasiado sencillo, ya sabía lo que hacía antes de que acabaran los vídeos (aunque para el segundo ya tenía ventaja).
Eso sí, el novato es más correcto, si no me equivoco es Phyton y al imprimir una lista imprime los corchetes, no sólo los números
Es que el novato va dando saltos de arriba a en medio a abajo sin mucho sentido, mientras el experto va en orden, hasta que no entiende una sección, no pasa a la siguiente. Lo lógico vamos.
Esto es más una curiosidad que no demuestra nada. En mi caso alguna vez aprendiendo algo de programación me he topado con gente que pone en los comentarios lo que quiere hacer, pero NO lo que hace, ni mucho menos el cómo.
¿Qué es para ellos un novato? ¿Alguien que acaba de salir de la universidad, alguien que está en primero de carrera? ¿Y un experto? ¿Es alguien con un par de años de experiencia, con diez, o alguien que solo dice "yo sé mucho porque programo en Lunix"?