423 meneos
24034 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
negativos: 13   usuarios: 215   anónimos: 208  
compartir:  twitter  facebook  tuenti  
  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!
    637  votos: 74   link
    el 23-12-2012 07:35 UTC por ElPerroDeLosCinco ElPerroDeLosCinco
  2. #2   #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
    59  votos: 8   link
    el 23-12-2012 09:52 UTC por Grohl Grohl
  3. #3   Pues será muy experto, pero la caga.
    18  votos: 1   link
    el 23-12-2012 10:28 UTC por malapersona malapersona
  4. #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
    130  votos: 14   link
    el 23-12-2012 10:40 UTC por safull safull
  5. #5   Me gustaría ver qué cambios se producen cuando hay resaltado de sintaxis.
    48  votos: 5   link
    el 23-12-2012 10:50 UTC por code2011 code2011
  6. #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/
    60  votos: 6   link
    el 23-12-2012 12:12 UTC por elephants_running elephants_running
  7. #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.
    105  votos: 11   link
    el 23-12-2012 12:29 UTC por FrEeDoOm FrEeDoOm
  8. #8   Yo lo hago así: i.imgur.com/xVyoSl.jpg
    138  votos: 15   link
    el 23-12-2012 12:53 UTC por UsuarioBorrado UsuarioBorrado
  9. #9   #4 El tema es que si no pones el mismo código... pues como que el vídeo no tiene mucho sentido :-S
    176  votos: 20   link
    el 23-12-2012 12:55 UTC por Suckelo Suckelo
  10. #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).
    30  votos: 5   link
    el 23-12-2012 12:58 UTC por Vermelnardo Vermelnardo
  11. #11   Yo ya estoy muy oxidado, a ver si vuelvo a los cursos de Udacity. :-) Programar mola con ellos.
    7  votos: 0   link
    el 23-12-2012 13:00 UTC por SpeakerBR SpeakerBR
  12. #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
    228  votos: 27   link
    el 23-12-2012 13:00 UTC por grails grails
  13. #13   Titular alternativo: "Cómo dos personas distintas leen un trozo de código". Cantidad de información extraible: 0
    92  votos: 9   link
    el 23-12-2012 13:01 UTC por quidam quidam
  14. #14   Yo soy mas de Cobol.
    24  votos: 2   link
    el 23-12-2012 13:01 UTC por bensidheseleccion bensidheseleccion
  15. #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:
    126  votos: 15   link
    el 23-12-2012 13:02 UTC por mercenario mercenario
  16. #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.
    10  votos: 0   link
    el 23-12-2012 13:02 UTC por ArdiIIa ArdiIIa
  17. #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"?
    -17  votos: 5   link
    el 23-12-2012 13:03 UTC por trollazo trollazo
  18. #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)
    13  votos: 1   link
    el 23-12-2012 13:03 UTC por maxpowel maxpowel
  19. #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.
    54  votos: 6   link
    el 23-12-2012 13:06 UTC por FrEeDoOm FrEeDoOm
  20. #20   #19 hombre, es para que "quede mas estructurado el código" xD
    15  votos: 1   link
    el 23-12-2012 13:08 UTC por grails grails
  21. #21   #1 los comentarios son innecesarios, la mejor documentación son test unitarios y funcionales claros y sencillos
    27  votos: 8   link
    el 23-12-2012 13:10 UTC por Blaxter Blaxter
  22. #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.
    16  votos: 1   link
    el 23-12-2012 13:10 UTC por elephants_running elephants_running
  23. #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...
    39  votos: 4   link
    el 23-12-2012 13:13 UTC por CuaC CuaC
  24. #24   #15 Y de Hans Reiser :-D
    33  votos: 3   link
    el 23-12-2012 13:13 UTC por erthed erthed
  25. #25   #8 Oye canino, cuando quieras nos batimos en duelo. :-P :-D :-D  media
    66  votos: 7   link
    el 23-12-2012 13:16 UTC por f2105 f2105
  26. #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
    111  votos: 13   link
    el 23-12-2012 13:17 UTC por jmpep jmpep
  27. #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!
    6  votos: 0   link
    el 23-12-2012 13:17 UTC por Artik Artik
  28. #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.
    122  votos: 17   link
    el 23-12-2012 13:20 UTC por radioman radioman
  29. #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.
    21  votos: 1   link
    el 23-12-2012 13:25 UTC por mercenario mercenario
  30. #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"...
    46  votos: 4   link
    el 23-12-2012 13:34 UTC por radioman radioman
  31. #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.
    38  votos: 4   link
    el 23-12-2012 13:36 UTC por Penetrator Penetrator
  32. #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;
    }
    35  votos: 3   link
    el 23-12-2012 13:51 UTC por mercenario mercenario
  33. #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.
    }
    257  votos: 34   link
    el 23-12-2012 13:55 UTC por Ganimedes Ganimedes
  34. #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
    61  votos: 6   link
    el 23-12-2012 13:57 UTC por radioman radioman
  35. #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.
    36  votos: 3   link
    el 23-12-2012 13:59 UTC por manumaldonado manumaldonado
  36. #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
    7  votos: 0   link
    el 23-12-2012 14:02 UTC por Kherom Kherom
  37. #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
    20  votos: 1   link
    el 23-12-2012 14:06 UTC por mercenario mercenario
  38. #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.
    38  votos: 4   link
    el 23-12-2012 14:16 UTC por roig roig
  39. #39   Errónea como una casa de grande. No están analizando el mismo código.
    30  votos: 2   link
    el 23-12-2012 14:32 UTC por ragar ragar
  40. #40   while(1){
    fork();
    }
    19  votos: 1   link
    el 23-12-2012 14:48 UTC por Aladaris Aladaris
  41. #41   #39 goto #38
    17  votos: 1   link
    el 23-12-2012 15:08 UTC por roig roig
  42. #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/
    63  votos: 6   link
    el 23-12-2012 15:08 UTC por elephants_running elephants_running
  43. #43   #28 precisamente el otro día estuve revisando el código del gcc y me pasó lo que dices
    29  votos: 2   link
    el 23-12-2012 15:16 UTC por patotemato patotemato
  44. #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...
    9  votos: 0   link
    el 23-12-2012 15:20 UTC por nergeia nergeia
  45. #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.
    10  votos: 0   link
    el 23-12-2012 15:22 UTC por pollo pollo
  46. #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.
    36  votos: 3   link
    el 23-12-2012 15:26 UTC por Tolker Tolker
  47. #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
    20  votos: 2   link
    el 23-12-2012 15:26 UTC por Trublux Trublux
  48. #48   #44 Pues les está dando una buena razón para echarle.
    7  votos: 0   link
    el 23-12-2012 15:28 UTC por Kherom Kherom
  49. #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.
    18  votos: 2   link
    el 23-12-2012 15:29 UTC por Undead Undead
  50. #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).
    10  votos: 0   link
    el 23-12-2012 15:30 UTC por Cidwel Cidwel
  51. #51   El código es la documentación definitiva. Para bien y para mal.
    15  votos: 1   link
    el 23-12-2012 15:34 UTC por hurd hurd
  52. #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.
    6  votos: 0   link
    el 23-12-2012 15:49 UTC por sauron34_1 sauron34_1
  53. #53   #49 En mi opinion, no es cuestion de codigo mas complicado o menos complicado, sino mas EFICIENTE o menos EFICIENTE.
    9  votos: 0   link
    el 23-12-2012 15:55 UTC por ander_bg ander_bg
  54. #54   Los códigos son diferentes y el experto pone el resultado mal. :-S
    13  votos: 1   link
    el 23-12-2012 16:00 UTC por Hectronic0 Hectronic0
  55. #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.
    33  votos: 2   link
    el 23-12-2012 16:28 UTC por klam klam
  56. #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
    24  votos: 2   link
    el 23-12-2012 16:40 UTC por batiscafo batiscafo
  57. #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
    8  votos: 0   link
    el 23-12-2012 16:55 UTC por Potopo Potopo
  58. #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.
    15  votos: 1   link
    el 23-12-2012 16:59 UTC por pitogrillo pitogrillo
  59. #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.
    18  votos: 1   link
    el 23-12-2012 17:15 UTC por guigar guigar
  60. #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!!!
    13  votos: 1   link
    el 23-12-2012 17:31 UTC por tualotuyo tualotuyo
  61. #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.
    14  votos: 1   link
    el 23-12-2012 17:43 UTC por ClaudioFioli ClaudioFioli
  62. #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
    16  votos: 1   link
    el 23-12-2012 18:24 UTC por Lb2A3qA Lb2A3qA
  63. #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.
    7  votos: 0   link
    el 23-12-2012 18:26 UTC por Lb2A3qA Lb2A3qA
  64. #64   #24 Oh, el buen Reiser... un sistema de archivos matador.
    8  votos: 0   link
    el 23-12-2012 18:35 UTC por paul21 paul21
  65. #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.
    10  votos: 0   link
    el 23-12-2012 20:12 UTC por klam klam
  66. #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.
    30  votos: 2   link
    el 23-12-2012 20:19 UTC por alt alt
  67. #67   ¿Conocéis la unidad de medida de la calidad de un programa? El WTF por minuto: codinghorror.typepad.com/.a/6a0120a85dcdae970b012877707a45970c-pi
    40  votos: 4   link
    el 23-12-2012 21:30 UTC por jorge_p jorge_p
  68. #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.
    12  votos: 1   link
    el 23-12-2012 22:14 UTC por Undead Undead
  69. #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.
    29  votos: 2   link
    el 23-12-2012 22:57 UTC por jorgeas80 jorgeas80
  70. #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.
    16  votos: 1   link
    el 23-12-2012 22:58 UTC por borjab borjab
  71. #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.
    43  votos: 4   link
    el 24-12-2012 00:01 UTC por manumaldonado manumaldonado
  72. #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...
    9  votos: 0   link
    el 24-12-2012 01:06 UTC por Lochi Lochi
  73. #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/
    9  votos: 0   link
    el 24-12-2012 04:59 UTC por humitsec humitsec
  74. #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).
    6  votos: 0   link
    el 24-12-2012 14:07 UTC por Undead Undead
  75. #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.
    7  votos: 0   link
    el 24-12-2012 16:42 UTC por Kherom Kherom
  76. #76   #33 dioooos me he estado riendo un ratazo largo y lo peor ha sido intentar explicárselo a mi madre >_<
    7  votos: 0   link
    el 24-12-2012 17:18 UTC por Schani Schani
  77. #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.
    8  votos: 0   link
    el 24-12-2012 17:21 UTC por Potopo Potopo
  78. #78   #77 Todo se aprende ;)
    7  votos: 0   link
    el 24-12-2012 17:26 UTC por Kherom Kherom
  79. #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.
    6  votos: 0   link
    el 25-12-2012 18:31 UTC por Arth Arth
comentarios cerrados

menéame