A los que os dedicáis a esto, cuando queréis modificar un programa o simplemente estudiar su funcionamiento, ¿cómo leéis su código fuente? Es decir, ¿vais directamente a los comentarios? ¿Intentáis primero "descifrar" el código? ¿U os vais directamente a la función principal y vais leyendo las funciones secundarias a medida que éstas van siendo llamadas?
En definitiva, ¿hay alguna técnica universal to wapa para leer código fuente sin perderse en mares de variables?
Hola Richard. Estoy de acuerdo con lo de los comentarios, y hablando de ellos, creo que una buena manera de documentar un programa sería hacer algo así como un "índice" de las funciones a utilizar (antes de empezar con el código propiamente dicho) con una ordenación así:
/* ------ Programa tal ------- *
* main(argumentos) *
* ____subfunciones (las barras bajas representan espacios)
* __________subsubfunciones
* etc */
Esto lo vi una vez en un programa, lo cachondo es que éste no llegaba a las 100 líneas de código 
Pero estaría muy, muy bien que la gente documentara de esta forma sus programas en vez de limitarse a poner un comentario a cada línea.
Ahora bien, respecto a esa lectura por capas, ¿sueles ayudarte de un papel y un boli para apuntarte las variables importantes o algo? Porque yo por lo menos me pierdo bastante en este tema.
Yo normalmente lo que hago es correr vagamente el código de arriba a abajo y luego vuelta de nuevo para ver más o menos el estilo que usa el fulano a la hora de programar. Miro cómo escribe las funciones y cómo declara las variables. Y nada, a la hora de modificar, dependiendo de la magnitud de la modificación o me basta con Control + F y buscar alguna cadena que me sirva de referencia o empezar a leer desde el main.
No sé, ahora que lo dices, no tengo un método estándar para eso. De los comentarios no me suelo fiar porque cada cual comenta los programas como le sale de lapuntalnabo, y como dice una de las frases del fortune:
- Los verdaderos programadores no documentan sus programas. El código es obvio.
No quiero decir que no haya que comentar los programas, al contrario. Pero a mí, a la hora de intentar leer código nunca me han ayudado más allá de comprender cómo hace algo una determinada función.
Luego, hay ciertas cosas que yo llamo la "documentación implícita", que si bien no son comentarios per-se son ciertas cosas que ayudan a moverte. Por ejemplo, ordenar el programa según este criterio:
- Inclusiones de cabeceras
- Definiciones de símbolos
- Estructuras y typedefs
- Variables globales estáticas
- Variables globales externas
- Variables globales normales
- Prototipos de las funciones usadas, menos el main
- Definición de esas funciones
- main
Que hace que lo único que tengas que hacer sea abrir el archivo en dos ventanas (jkjokjojk ventaja de usar dos monitores, aunque realmente esto no es necesario): en una lo tienes abierto por la parte de las variables y prototipos, y en la otra lo tienes abierto en el código que estás editando. Así, si por ejemplo, ves que una función llama a haz_x() y le pasa varios parámetros, puedes hacerte una idea de lo que hace viendo su prototipo en la otra ventana.
¿Qué pasa? Que cada cual ordena según el criterio que más le gusta. Pero según qué códigos leas hay convenios y convenios. Los programas de GNU, por ejemplo, tienen que seguir ciertos patrones a la hora de codificar porque el volumen de código a manejar es tan bestial que sin un poco de orden y acuerdo se harían indepurables.
Y bueno, huelga decir que hay más criterios a la hora de segmentar el programa en varios archivos y bibliotecas, pero eso ya es otra historia.
Los verdaderos programadores no documentan sus programas. El código es obvio.
Claro en especial con variables-funciones llamadas:
o mi favorita:
Ovbiamente ninguna documentada y definidas estrategicamente en cualquier lado del programa (Bienaventurados aquellos que programan con convenios y en lenguajes que obligan cierto orden).
Por decencia uno deberia colocar los comentarios minimos quien, cuando, para que, que entra y que sale. todo ello sin llegar a la exageracion.
Hay que tener intuicion (ademas de experiencia, tolerancia, paciencia y en ocaciones aplomo) para comprender la logica de los otros programadores
Hola Richard. Estoy de acuerdo con lo de los comentarios, y hablando de ellos, creo que una buena manera de documentar un programa sería hacer algo así como un "índice" de las funciones a utilizar (antes de empezar con el código propiamente dicho) con una ordenación así:
/* ------ Programa tal ------- *
* main(argumentos) *
* ____subfunciones (las barras bajas representan espacios)
* __________subsubfunciones
* etc */
Esto lo vi una vez en un programa, lo cachondo es que éste no llegaba a las 100 líneas de código
Ahora bien, respecto a esa lectura por capas, ¿sueles ayudarte de un papel y un boli para apuntarte las variables importantes o algo? Porque yo por lo menos me pierdo bastante en este tema.
Ojo, coincido con lo que dijeron: "un buen programa no necesita documentacion". El problema es que de los cientos de codigos fuentes que he leido, solo uno o dos estan tan bien escritos que no necesitan comentarios.
Por lo general te encuentras con funciones como:
int rfdedv(int c) {}
..y te pasas media vida tratando de entender que quiere decir para darte cuenta mas tarde que significa "resultado final de exportaciones de vacas" (esto es un caso cierto).
Creo que la experiencia es la mejor herramienta a la hora de leer codigo. Cuando llevas cierto tiempo, con solo leer algunas cosas del codigo, puedes meterte en la mente del programador y saber como piensa. Lo malo es que a veces te encuentras con codigo de programadores expertos que estan con un par de tornillos flojos y el codigo que lees es una pesadilla.
Respondiendo a tu pregunta: no suelo usar papel y lapiz, mentalmente armo un esquema. Si la cantidad de codigo es mucha, suelo armar un "mapa" de las funciones vitales del programa, pero no mas que eso.
Usualmente si debo trabajar con el codigo de otra persona, le agrego mis propios comentarios. Un buen editor de codigo ayuda mucho, sobre todo uno que ponga identaciones automaticas y lineas de separacion entre funciones.
Usualmente si debo trabajar con el codigo de otra persona, le agrego mis propios comentarios. Un buen editor de codigo ayuda mucho, sobre todo uno que ponga identaciones automaticas y lineas de separacion entre funciones.
Eso es MUY importante.
No sé si soy sólo yo, pero una vez que te acostumbras, si te vas al Bloc de Notas a programar te puedes frustrar.
Ay, recuerdo mis primeros programas en C 
. Ni tabulación ni leches todo al mismo nivel. Ni yo lo entendía xD
Aunque creo que ninguno de nosotros le haga el quite a un editor que idente (y resalte el codigo), esto es un arma de doble filo porque al final de cuentas terminamos dependiendo del editor (Y mas cuando el tiempo apremia) despues nos enfrentamos con los tipicos lios de la codificacion del archivo, que si es un tabulador o 4 espacios , entre otras molestias.
Digamos casos concretos como desarrollos codificados en un editor (Digamos Notepad++, que es el que mas utilizo) que luego otro desarrollador maneja en Visual Studio (xx y xy),o Dreamweaver, cuando vas a ver tu codigo, te puedes encontrar con algo totalmente diferente.
Nah, lo mejor es tabular siempre con espacios, porque un tabulador yo lo veo con ocho espacios, y fulanito lo ve con cuatro.
No sé si soy sólo yo, pero una vez que te acostumbras, si te vas al Bloc de Notas a programar te puedes frustrar.
Ojo. Yo soy de los que usan el Bloc de Notas o programas similares para escribir codigo. Uso editores como el Notepad++ o el PSPad cuando tengo que leer codigos de otros, pues me simplifican mucho la tarea.
Siempre trato de usar varios editores diferentes, de esta manera puedo trabajar con cualquiera en el caso de que el ordenador que este usando no disponga de mi editor favorito. Ademas, muchos editores de codigos buenos estan empezando a tener versiones portables y no salgo de casa sin un pendrive :D
Creo que todo programador que se precie deberia poder escribir codigo "a la antigua": simples y puros editores estilo notepad. :-)
Honestamente el Block de Notas (De Windows) me parece terriblemente limitado(pero funcional a fin de cuentas), para programar, de no tener mas utilizo el Wordpad, que tiene un poquito mas pero en mi memoria USB van conmigo siempre el Notepad++, el Crimsom editor, Winmerge y el instalador del Textpad, cosa que no me quede varado por herramientas.
Porque en grandes carpetas con codigo, archivos gigantestos con codigo, en especial los mesclados como los ASP clasicos, es buena idea tener algo con potencia, mas a la hora de Buscar segmentos de codigo.
Honestamente el Block de Notas (De Windows) me parece terriblemente limitado(pero funcional a fin de cuentas), para programar, de no tener mas utilizo el Wordpad, que tiene un poquito mas pero en mi memoria USB van conmigo siempre el Notepad++, el Crimsom editor, Winmerge y el instalador del Textpad, cosa que no me quede varado por herramientas.
Porque en grandes carpetas con codigo, archivos gigantestos con codigo, en especial los mesclados como los ASP clasicos, es buena idea tener algo con potencia, mas a la hora de Buscar segmentos de codigo.
Para el tipo de codigo que estoy programando ahora, el notepad me basta y sobra (ahora me asignaron hacer la parte de javascript de un sitio web). Los codigos no tienen mas de 200 lineas, eso es nada comparado a las 10000+ lineas a las que estoy acostumbado a ver.
Cuando me toque hacer el "rejunte" con el resto de la pagina, usare algo con mas "power".
Prueba el PSPad. Yo lo llevo siempre en el pendrive, junto con el notepad++ y el ultraedit. Es bastante bueno y es free.
Para programación procedural, yo también suelo ir al programa principal directamente, y de ahí voy recorriendo funciones en profundidad (las relevantes), ayudándome de lápiz y papel.
A no ser que sea un proyecto Java, donde la navegación con Eclipse ahorra muchos esfuerzos y los esquemas que me hago son de otro tipo (UML).
Como se ha dicho, lamentablemente no se escriben ni programas "autolegibles", ni comentarios relevantes, la mayor parte de las veces. Muy a menudo se hace copy/paste y se modifica el código y no los comentarios. O se ponen comentarios "brillantes", como los que ya se han citado. Hay un tipo de comentario que me encanta:
// pongo laVariableQueSea a cero
laVariableQueSea = 0;
Tan malo es poner comentarios que despisten o sólo llenen espacio como no ponerlos.
Una práctica que tengo yo (ésta al escribir), si he de hacer algo medianamente largo, es escribir el esquema de lo que voy a codificar con comentarios y luego ir rellenando con código. Como se dice muchas veces, el código lo escribes una vez, pero se lee muchísimas. En tiempos me encontraba con que si no era cuidadoso con partes difíciles, aunque lo hubiera escrito yo, no era capaz de leerlo (o al menos, de leerlo y recordarlo tan rápido como querría).
Es una pena que en esto está todo inventado hace tiempo, y se siguen haciendo las cosas rematadamente mal...
A no ser que sea un proyecto Java, donde la navegación con Eclipse ahorra muchos esfuerzos y los esquemas que me hago son de otro tipo (UML).
Llevo pensando esto durante todo el hilo, ¿solo existen herramientas de depuración para Java? Porque a mí me quitas el debug y no valgo ni para programar el vídeo.
Hay para multitud de lenguages y entornos... Desde Cobol hasta Javascript, pasando por C++ (en modo gráfico o texto) y Visual Basic (he de reconocer, aunque soy habitualmente no partidario de Microsoft, que en su día tenía un IDE y unas herramientas de depuración cuya comodidad y rapidez no he visto superadas todavía por ninguna otra herramienta).
Depurar es a veces el único medio para averiguar qué se quería hacer, o cómo...
Llevo pensando esto durante todo el hilo, ¿solo existen herramientas de depuración para Java? Porque a mí me quitas el debug y no valgo ni para programar el vídeo.
Siempre habrá algún depurador por cutre o incomprensible que sea para cualquier lenguaje.
Vaya, que hasta dónde yo sé, incluso los lenguajes más ridículos (como la bazofia del Pascal Estándar Extendido que nos han mandado usar en primero) no se resisten a GDB. Y señalando el valor de las variables, la pila de llamadas, las líneas y todo; tampoco me refiero a un depurador súper-mega-jeik que sólo entienda de direcciones y ensamblador.
Ahora recuerdo otra "dificultad" y es toparte con Frameworks, muchos de ellos son la abstraccion abstraida, y como siempre la documentacion esta al alcance de la mano (de quien se invento el Framework).
OcioZero · Condiciones de uso
Los comentarios son la primer cosa que se suele usar. Si un codigo esta bien documentado, enseguida uno entiende todo. Lo malo es que encontrar codigo documentado como corresponde es algo muy raro.
Lo segundo es tratar de entender el pensamiento del programador que escribio el codigo. Si bien esto parece imposible, con experiencia uno puede lograrlo. Basta con leer algunas funciones del programa para entender la forma de pensar del programador: su nivel de experiencia, sus convenciones de codificacion, las formas de nombrar variables, sus defectos..
Un programador novato escribe codigo de una manera muy particular y tiende a usar sentencias simples. Un programador mas veterano tiende a "exprimir" mas el codigo y usa sentencias mas "oscuras" (esas en las que uno necesita del manual del compilador para entenderlas).
Naturalmente, uno sigue un orden para leer el codigo, se empieza por la funcion principal y luego por las funciones a la que este llama.
Lo que se suele hacer es leer la principal y todas a la que este llama. Despues se toma la primer subfuncion, se leen todas las funciones a la que este llama y luego se pasa a la siguiente subfuncion. Esta lectura "por capas" suele ayudar mucho.
Si uno solo quiere saber como funciona una parte del codigo, naturalmente uno solo lee ese segmento y listo.
Espero que esto haya respondido a tu pregunta.