Interpretación del código fuente de otros [cerrado]

Nota: Soy consciente de esta pregunta. Esta pregunta es un poco más específica y profunda, sin embargo, se centra en leer el código real en lugar de depurarlo o preguntarle al autor.

Como estudiante en una clase introductoria de ciencias de la computación, mis amigos ocasionalmente me piden que los ayude con sus tareas. La programación es algo de lo que estoy muy orgulloso, por lo que siempre estoy feliz de hacerlo. Sin embargo, generalmente tengo dificultades para interpretar su código fuente.

A veces esto se debe a un estilo extraño o inconsistente, a veces se debe a requisitos de diseño extraños especificados en la tarea, y a veces es solo debido a mi estupidez. En cualquier caso, termino luciendo como un idiota mirando la pantalla durante varios minutos diciendo "Uh ..."

Por lo general, primero verifico los errores comunes: faltan puntos y comas o paréntesis, uso comas en lugar de operadores de extracción, etc.

El problema viene cuando eso falla. A menudo no puedo seguir adelante con un depurador porque es un error de sintaxis, y a menudo no puedo preguntarle al autor porque él / ella no entiende las decisiones de diseño.

¿Cómo sueles leer el código fuente de los demás? ¿Lees el código de arriba hacia abajo o sigues cada función como se llama? ¿Cómo sabes cuándo decir "Es hora de refactorizar?"

Primer consejo: use un IDE (o un editor muy bueno :)) para detectar errores de sintaxis, paréntesis fuera de lugar y otros errores triviales.

Segundo paso: formatee automáticamente todo el código en un formato con el que se sienta cómodo. Uno pensaría que esto no importa mucho, pero sorprendentemente, sí.

No tenga miedo de cambiar el nombre de las variables locales si están mal nombradas. (Si tiene acceso al sistema completo, puede cambiar el nombre de cualquier cosa y debería hacerlo).

Agregue comentarios a usted mismo cuando descubra lo que está haciendo una determinada función / método.

Se paciente. Comprender el código alienígena no es fácil, pero siempre hay un momento decisivo en el que la mayoría de las piezas del rompecabezas de repente caen en su lugar. Hasta ese momento, todo es trabajo duro y trabajo pesado, me temo. La buena noticia es que con la práctica este momento eureka llegará antes.

Permítanme decir que creo que están tomando un enfoque equivocado con esto. Si la gente está pidiendo ayuda con su código, creo que usted tiene la responsabilidad de darse la vuelta y decirles que lo guíen a través de su código. Puede corregir sus errores por ellos, y pueden aprender algo (de memoria), si pueden detectar sus propios errores (con su ayuda) es probable que aprendan más. Además, obtendrá una experiencia más amplia sobre cómo las diferentes personas se acercan a la codificación (lo que a su vez le permitirá leer / comprender más código), un ciclo virtuoso ...;)

Creo que esta habilidad es una mezcla de experiencia y simplemente tener un talento para ello. Hemos tenido empleados que podrían resolver más o menos cualquier cosa si les pidiéramos que hicieran algo desde cero, al mismo tiempo que no pudiéramos encontrar errores obvios en los fragmentos de código que no escribieron. Y, simultáneamente, hemos tenido empleados en los que no confiaríamos con nada que exceda el diseño básico, pero que podrían sumergirse en el código de otros y rastrear problemas en poco tiempo.

Dicho esto, la forma de abordar esto es cambiar el código. Vuelva a formatearlo a lo que está acostumbrado, cambie los nombres de las variables a algo que tenga sentido para usted, agregue comentarios si el código no está claro. Si él le pidió ayuda, debe seguir adelante y cambiar las cosas hasta que detecte el problema. Luego, deje que su amigo corrija el código original o use el suyo.

Primero, si hay errores de sintaxis, simplemente tiene que leer los errores del compilador cuidadosamente. A menudo, una línea se resalta como un error, pero en realidad fue la línea anterior la que tiene el error.

Tenga en cuenta que, para un estudiante introductorio, puede haber algunos artefactos de edición que evitarán que se compile el programa que no se puede ver. Por ejemplo, una vez vi a un estudiante (no uno mío) que usaba la barra espaciadora en lugar de regresar: su código parecía normal en un editor que se ajustaba después de 80 columnas (el estudiante fue muy paciente), y el código incluso funcionó hasta que agregó una "// comentario al estilo ", que comentaba todo el resto del programa. De manera similar, si copia ejemplos de código de un sitio web, a menudo también se copian caracteres no imprimibles (dependiendo de cómo el sitio web formateó el código). En caso de duda, vuelva a escribir una línea sin copiar y pegar. [Es sorprendente, pero lo he visto suceder mucho más últimamente.]

Para errores desagradables del compilador, es posible que tenga que hacer crecer el programa, creando un nuevo archivo y escribiendo todo el código a medida que avanza. Asegúrese de compilar después de cada paso importante antes de pasar al siguiente.

Bien, ¿y si no hay errores de sintaxis? ¡Entonces es hora de pasar por el código! Puede usar un depurador para esto, pero realizar llamadas a printftodo el código también es muy efectivo. Por ejemplo, si hay un forciclo, agregue una declaración de impresión para el contador del ciclo. En el caso de los forbucles anidados , es posible que se incremente la variable incorrecta.

La ventaja de usar printfs es su capacidad de "comprimir" en el tiempo / espacio lo que estás viendo actualmente. Cuando te encuentras con un depurador, también ves mucho estado irrelevante y puede ser más tedioso. Además, sin ver un historial de lo que se ha impreso en la consola, puede perder algunos patrones. El punto aquí es que el depurador y printfs son técnicas complementarias, y ninguno es siempre mejor que el otro.

Finalmente, ¡simplemente pregúntale a tu amigo qué está pasando! En lugar de mirarlo y decir "uh" pregúnteles qué están haciendo: "¿y ahora qué hace n?" Al iniciar el diálogo, pueden terminar respondiendo su propia pregunta, o puede darse cuenta de la forma en que conceptualizaron que el programa tenía una falla, que puede llevarlo a una solución.

Como se comentó en otra parte, todo esto mejora con la experiencia. A pesar de que he estado programando durante 20 años, no fue hasta los últimos 5 años que estuve trabajando con estudiantes que mejoré al ayudarlos con sus errores.

Odio decir esto, pero no hay una bala de plata aquí.

Francamente, si fuera lo suficientemente clarividente como para poder entender lo que los demás querían decir cuando escribieron lo que hicieron, incluso en el 10% de los casos, sin duda alguna ya habría ganado millones.

En una nota más práctica, el uso de un IDE inteligente es el paso 1.

El paso 2 sería ejecutar doxygen o algo similar para descubrir la jerarquía del código fuente.

El paso 3 es encontrar funciones u objetos de anclaje, cosas que procesan su línea de comando o archivo y luego realizan la lógica.

Paralelamente al Paso 3, realice un seguimiento de los globales si los está utilizando. También pregunte a sus compañeros si están usando algún algoritmo específico conocido; leer el algoritmo (si existe) antes de mirar el código siempre es beneficioso.

En una palabra: experiencia, cuanto más experiencia obtengas, más aprenderás de las mejores prácticas y podrás juzgar / comprender el código de otras personas. ¡No viene automáticamente, sino que a menudo solo viene de cometer el mismo error usted mismo!

Dicho esto, es esencial que los programadores aprendan a comentar su código correctamente porque cuando se mira el código, a menudo es solo el resultado de un proceso de pensamiento importante que a menudo es muy difícil de extrapolar del código. Algunos comentarios, un archivo de texto con ideas de diseño puede marcar la diferencia entre comprender el código y malinterpretarlo por completo.

A menudo me preguntaban lo mismo en el laboratorio de la escuela. Por lo general, la pregunta comenzó con "¿Cómo soluciono este error del compilador?" así que me volví bastante bueno para detectar colgantes else, puntos y comas faltantes y demás . (También #define CUBE(x) x * x * xes divertido depurar las macros, es un error que todos estamos destinados a cometer). Una ventaja que tuve fue que había asistido a las mismas clases con los mismos maestros, por lo que ya estaba familiarizado con los requisitos.

El proceso que mejor funcionó es mantener un cuadro de diálogo en ejecución. No desea escribir el programa para ellos, ya que son los que necesitan aprender. Esto significa que tienes que estar en la misma computadora con ellos. En el laboratorio iría a su computadora. Intentaría que detectaran el error, comenzando con el mensaje del compilador. (Estábamos usando C.) Comience con el número de línea y señale dónde corresponden el mensaje y el error. Si hay más de uno del mismo error, les preguntaría qué fue similar sobre los dos errores.

La idea es ayudar a guiar al otro estudiante. Reescribir su código para ellos no los ayudará a aprender.

Los errores de sintaxis son mucho más fáciles de encontrar que los errores lógicos. Si la mayoría de sus problemas son sintaxis, busque un IDE, copie y pegue su código en él y corrija los errores. Los errores lógicos son mucho más difíciles. No estoy seguro de por qué dices que no puedes pedirles que expliquen su código. He encontrado muchos errores lógicos al explicar el código a otra persona.