423 meneos
24251 clics

Video de como un programador novato vs experto rastrea código con sus ojos  vídeo

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).
etiquetas: video, código, ingeniería, programación, software
usuarios: 215   anónimos: 208   negativos: 13  
79comentarios mnm karma: 632
  1. #1   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, cabrones amigos programadores!
    votos: 74    karma: 637
  2. #3   Pues será muy experto, pero la caga.
    votos: 1    karma: 18
  3. #4   #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
    votos: 14    karma: 130
     *   safull safull
  4. #5   Me gustaría ver qué cambios se producen cuando hay resaltado de sintaxis.
    votos: 5    karma: 48
  5. #6   #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: docs.djangoproject.com/
    votos: 6    karma: 60
  6. #7   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.
    votos: 11    karma: 105
  7. #8   Yo lo hago así: i.imgur.com/xVyoSl.jpg
    votos: 15    karma: 138
  8. #9   #4 El tema es que si no pones el mismo código... pues como que el vídeo no tiene mucho sentido :-S
    votos: 20    karma: 176
  9. #10   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).
    votos: 5    karma: 30
  10. #11   Yo ya estoy muy oxidado, a ver si vuelvo a los cursos de Udacity. :-) Programar mola con ellos.
    votos: 0    karma: 7
     *   SpeakerBR SpeakerBR
  11. #12   #1 Hay que comentar, pero comentar lo necesario y no poner comentarios del tipo

    //empieza el if
    if (...) {
    int i = 0; //inicializo la variable a cero.

    if (i == 1) { //compruebo que la variable i sea igual a uno
    } //termina if


    Esto es desesperante para un programador
    votos: 27    karma: 228
  12. #13   Titular alternativo: "Cómo dos personas distintas leen un trozo de código". Cantidad de información extraible: 0
    votos: 9    karma: 92
  13. #14   Yo soy mas de Cobol.
    votos: 2    karma: 24
  14. #15   #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 :troll:
    votos: 15    karma: 126
  15. #16   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.
    votos: 0    karma: 10
  16. #17   ¿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"?
    votos: 5    karma: -17
  17. #18   #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)
    votos: 1    karma: 13
  18. #19   #12

    // Si i es igual a 1 entonces devolvemos true
    if(i==1) { return true; }

    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.
    votos: 6    karma: 54
     *   FrEeDoOm FrEeDoOm
  19. #20   #19 hombre, es para que "quede mas estructurado el código" xD
    votos: 1    karma: 15
  20. #21   #1 los comentarios son innecesarios, la mejor documentación son test unitarios y funcionales claros y sencillos
    votos: 8    karma: 27
  21. #22   #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.
    votos: 1    karma: 16
  22. #23   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...
    votos: 4    karma: 39
  23. #24   #15 Y de Hans Reiser :-D
    votos: 3    karma: 33
  24. #25   #8 Oye canino, cuando quieras nos batimos en duelo. :-P :-D :-D  media
    votos: 7    karma: 66
  25. #26   #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 xD
    votos: 13    karma: 111
  26. #27   #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!
    votos: 0    karma: 6
  27. #28   #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 :palm:

    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.
    votos: 17    karma: 122
  28. #29   #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.

    Edit: #26 Tampoco es eso, a mí personalmente no me gusta el código redundante, en plan explicar con manzanas, si esta bien hecho se entiende solo, no hay que convertirlo directamente a pseudo-código.
    votos: 1    karma: 21
     *   --9388-- --9388--
  29. #30   #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)
    {
    int ch, ret;
    int aligned_samples = FFALIGN(nb_samples, 16);

    for (ch = 0; ch < channels; ch++) {
    DitherState *state = &c->state[ch];

    if (state->noise_buf_size < aligned_samples) {
    ret = generate_dither_noise(c, state, nb_samples);
    if (ret < 0)
    return ret;
    } else if (state->noise_buf_size - state->noise_buf_ptr < aligned_samples) {
    state->noise_buf_ptr = 0;
    }

    if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) {
    quantize_triangular_ns(c, state, dst[ch], src[ch], nb_samples);
    } else {
    c->quantize(dst[ch], src[ch],
    &state->noise_buf[state->noise_buf_ptr],
    FFALIGN(nb_samples, c->samples_align));
    }

    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"...
    votos: 4    karma: 46
     *   radioman radioman
  30. #31   #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 . 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.
    votos: 4    karma: 38
  31. #32   #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)
    {
    int ch, ret;

    // Obtengo un alineo de 16¿ de muestra
    int aligned_samples = FFALIGN(nb_samples, 16);

    // Repasamos canales para limpiar niebla¿
    for (ch = 0; ch < channels; ch++) {
    DitherState *state = &c->state[ch];

    // Si el tamaño del sampleo del video es menor, corregimos y seguimos para delante.
    if (state->noise_buf_size < aligned_samples) {
    ret = generate_dither_noise(c, state, nb_samples);
    if (ret < 0) ret; // <<<< WHAT?
    } else if (state->noise_buf_size - state->noise_buf_ptr < aligned_samples) { state->noise_buf_ptr = 0;}

    // Si el metodo del contexto es triangular, le hacemos cosas
    if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) {
    quantize_triangular_ns(c, state, dst[ch], src[ch], nb_samples);
    } else {
    c->quantize(dst[ch], src[ch], &state->noise_buf[state->noise_buf_ptr], FFALIGN(nb_samples, c->samples_align));
    }

    // Suma y sige
    state->noise_buf_ptr += aligned_samples;
    }

    return 0;
    }
    votos: 3    karma: 35
  32. #33   #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)
    {
    int ch, ret; //Declaro variables para tiemnpo de cocción de fideos y diámetro cacerola
    int aligned_samples = FFALIGN(nb_samples, 16); //Número de plumas en ala izquierda de la paloma

    for (ch = 0; ch < channels; ch++) {
    DitherState *state = &c->state[ch]; //Canto channels veces el "Cara al sol"

    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) {//Alineo las cartas impares del Tarot
    state->noise_buf_ptr = 0; //Suelto una ventosidad
    }

    if (c->method == AV_RESAMPLE_DITHER_TRIANGULAR_NS) { //Si el karma en meneame está por los suelos
    quantize_triangular_ns(c, state, dst[ch], src[ch], nb_samples); //Postear videos de gatitos
    } else {
    c->quantize(dst[ch], src[ch],
    &state->noise_buf[state->noise_buf_ptr],
    FFALIGN(nb_samples, c->samples_align)); //Agotar cupones de descuento en el Carrefour
    }

    state->noise_buf_ptr += aligned_samples; // Despolariza todos los cofluxores.
    }

    return 0; //Devuelve la nota de mi examen de programación.
    }
    votos: 34    karma: 257
  33. #34   #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 :-D :-D :-D
    votos: 6    karma: 61
     *   radioman radioman
  34. #35   #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.
    votos: 3    karma: 36
  35. #36   El novato es novato novato, madre lo que le cuesta :-P 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 :-P
    votos: 0    karma: 7
  36. #37   #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 :troll:

    #35 No sabes lo que te puedes encontrar hasta que toca lidiar con el, eso te lleva a #15 :-D
    votos: 1    karma: 20
     *   --9388-- --9388--
  37. #38   #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.
    votos: 4    karma: 38
  38. #39   Errónea como una casa de grande. No están analizando el mismo código.
    votos: 2    karma: 30
  39. #40   while(1){
    fork();
    }
    votos: 1    karma: 19
     *   Aladaris Aladaris
  40. #41   #39 goto #38
    votos: 1    karma: 17
  41. #42   #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:
    jacobian.org/writing/great-documentation/
    votos: 6    karma: 63
  42. #43   #28 precisamente el otro día estuve revisando el código del gcc y me pasó lo que dices
    votos: 2    karma: 29
  43. #44   #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...
    votos: 0    karma: 9
  44. #45   #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.
    votos: 0    karma: 10
     *   pollo pollo
  45. #46   #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.
    votos: 3    karma: 36
     *   Tolker Tolker
  46. #47   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.
    coderfacts.com/post/18600518280
    votos: 2    karma: 20
     *   Trublux Trublux
  47. #48   #44 Pues les está dando una buena razón para echarle.
    votos: 0    karma: 7
  48. #49   #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.
    votos: 2    karma: 18
  49. #50   #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).
    votos: 0    karma: 10
     *   Cidwel Cidwel
  50. #51   El código es la documentación definitiva. Para bien y para mal.
    votos: 1    karma: 15
     *   hurd hurd
  51. #52   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.
    votos: 0    karma: 6
  52. #53   #49 En mi opinion, no es cuestion de codigo mas complicado o menos complicado, sino mas EFICIENTE o menos EFICIENTE.
    votos: 0    karma: 9
  53. #54   Los códigos son diferentes y el experto pone el resultado mal. :-S
    votos: 1    karma: 13
  54. #55   #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 docs.oracle.com/javase/7/docs/api/java/util/regex/MatchResult.html con 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.
    votos: 2    karma: 33
  55. #56   #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
    votos: 2    karma: 24
     *   batiscafo batiscafo
  56. #57   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
    votos: 0    karma: 8
  57. #58   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.
    votos: 1    karma: 15
     *   pitogrillo pitogrillo
  58. #59   #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.
    votos: 1    karma: 18
  59. #60   #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!!!
    votos: 1    karma: 13
     *   tualotuyo tualotuyo
  60. #61   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.
    votos: 1    karma: 14
  61. #62   #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
    votos: 1    karma: 16
  62. #63   #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.
    votos: 0    karma: 7
  63. #64   #24 Oh, el buen Reiser... un sistema de archivos matador.
    votos: 0    karma: 8
  64. #65   #63 Creo que usé un mal ejemplo. Mira la documentación de regex de PHP 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.
    votos: 0    karma: 10
  65. #66   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.
    votos: 2    karma: 30
    alt alt
  66. #67   ¿Conocéis la unidad de medida de la calidad de un programa? El WTF por minuto: codinghorror.typepad.com/.a/6a0120a85dcdae970b012877707a45970c-pi
    votos: 4    karma: 40
  67. #68   #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.
    votos: 1    karma: 12
     *   Undead Undead
  68. #69   #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.
    votos: 2    karma: 29
  69. #70   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.
    votos: 1    karma: 16
  70. #71   #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.
    votos: 4    karma: 43
  71. #72   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...
    votos: 0    karma: 9
  72. #73   #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] www.cleancoders.com/
    votos: 0    karma: 9
  73. #74   #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).
    votos: 0    karma: 6
  74. #75   #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.
    votos: 0    karma: 7
  75. #76   #33 dioooos me he estado riendo un ratazo largo y lo peor ha sido intentar explicárselo a mi madre >_<
    votos: 0    karma: 7
  76. #77   #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.
    votos: 0    karma: 8
  77. #78   #77 Todo se aprende ;)
    votos: 0    karma: 7
  78. #79   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.
    votos: 0    karma: 6
comentarios cerrados

menéame