www.eliax.com/index.cfm?post_id=9885 por
Matroski el 23-12-2012 07:30 UTC publicado: 23-12-2012 12:50 UTC

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
Edito y aprovecho para reivindicar: ¡comentad vuestro código,
cabronesamigos programadores!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
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
Por ejemplo, muy buena documentación: docs.djangoproject.com/
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.
No solo me parece irrelevante (que entonces paso de menearla), sino que me parece sensacionalista (la voto como tal).
//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
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.
// 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.
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.
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...
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.
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.
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"...
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.
// 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;
}
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.
}
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
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.
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
#35 No sabes lo que te puedes encontrar hasta que toca lidiar con el, eso te lleva a #15
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.
fork();
}
“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/
Los únicos comentarios que ayudan en realidad son los que explican el por qué se hace algo que en principio no es obvio.
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.
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
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.
+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).
#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.
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
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
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.
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.
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.
- 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.
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.
//PEPITO
Y sí, Pepito ya no está en la empresa y no hay ni habrá forma de localizarle...
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/
#57 Css != Programación
#56 Especialmente con los "#endif // CONSTANT_LOQUESEA" que pueden llegar a ser muy largos.
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.