una duda sobre comentarios

[Kel]

Bueno en el canal de irc me ha surgido una duda interesante. He estado mirando el codigo de Daniel Navarro en los ejemplos... y todos sus juegos son comentados totalmente no se salta ni una línea y esto me hace pensar que estaría acostumbrado a comentar sus programas.

Pues me ha surgido esa duda, he leido en algún sitio que comentar antes de "codificar" ayuda al lado lógico mental, y por tanto es mejor comentar primero y despues pasar al "lenguaje", asi tienes mas o menos la idea sobre lo que quieres hacer. Lanzarse a programar de golpe y porrazo, para los que estén acostumbrados pues puede ser facil, pero que opinais sobre el tema de comentarios, ayudan o son simples recordatorios?

Es más que nada para ver qué opinais, gracias.

[Dluk]

Sinceramente, yo no uso comentarios, exceptuando en bloques. Por ejemplo, si una parte de un proceso hace que un personaje salte, entonces comienzo poniendo:

Extracto del código fuente del Megaman XS:

Code: Select all

/*ESTADO SALTO*/
        
        IF(estado==salto)    
            IF(salto_pegado==0)
                IF(ataque_saber==0)            
                    IF(animacion_salto[inc_anim_salto]<>0)
                        graph=animacion_salto[inc_anim_salto++];
                    ELSE
                        graph=animacion_salto[inc_anim_salto-1];
                    END 
                END     
            ELSE                

                IF(control_techo(x,y)==TRUE)
                    inc_x_avance=4;
                    salto_pegado=0;
                END
                
                IF(avance_x_pared<=3)    
                    inc_x_avance=0;
            
                    REPEAT                    
                        IF(control_pared_pegajosa(x+x_choque_pared,y,-21,25)==FALSE 
                          AND control_pared_pegajosa(x-x_choque_pared,y,-21,25)==FALSE)   
                                                 
                          IF(direccion_salto_pegado==0)
                              x+=1;
                          ELSE    
                              x-=1;
                          END
                          inc_x_avance+=1;                            
                        ELSE
                          inc_x_avance=velocidad_avance;
                        END
                    UNTIL(control_pared_pegajosa(x+x_choque_pared,y,-21,25)==TRUE 
                          OR control_pared_pegajosa(x-x_choque_pared,y,-21,25)==TRUE
                          OR inc_x_avance==velocidad_avance)                    
                END
                
                IF(ataque_saber==0)
                    IF(animacion_salto_pegado[inc_anim_salto]<>0)
                        graph=animacion_salto_pegado[inc_anim_salto++];                        
                    ELSE
                        graph=animacion_salto_pegado[inc_anim_salto-1];
                        salto_pegado=0;
                    END
                END
            END
                IF(control_techo(x,y)==FALSE)                
                    IF(inc_y_salto2<70 AND tecla_salto)
                        
                        valor_inc_salto-=1;
                        
                        REPEAT
                           IF(control_techo(x,y)==FALSE)
                               y-=1;
                               inc_y_salto+=1;
                               inc_y_salto2+=1;
                           ELSE
                               inc_y_salto2=70;
                               valor_inc_caida=0;
                           END
                        UNTIL(inc_y_salto2=>70 OR inc_y_salto>=valor_inc_salto)       
                        inc_y_salto=0;
                    ELSE
                        inc_y_salto=0;
                        inc_y_salto2=0;
                        inc_anim_salto=0;
                        
                        estado=normal;
                    END    
               ELSE
                   inc_y_salto=0;
                   inc_y_salto2=0;
                   inc_anim_salto=0;
                   valor_inc_caida=valor_inc_salto;
                   valor_inc_caida=0;
                   estado=normal;           
               END
        ELSE
            valor_inc_salto=alcance_salto; 
            salto_pegado=0;                                  
        END  

Pero fuera de eso, no uso comentarion de ningún tipo. Realmente no sé si está bien o mal, es que no me nace naturalmente hacerlo, normalmente me lanzo a programar directamente. De hecho, ni siquiera hago un diagrama antes de ir al código. No sé que opinarán los demás.

Saludos ^^

[Kel]

Gracias por responder Dluk. Ya veo que no usas comentarios... solo etiquetas secciones, lo cual veo acertado también, pues asi te organizas con todas las secciones. Hacía mucho tiempo que no programaba (por lo menos 10 años) y hace poco que empecé con gemix (despues de haber pasado por otros lenguajes en el pasado). Por ahora estoy organizando/comentando el código para tener un poco de estructura, pero veo que muchos de vosotros ni comentais nada y escribíis directamente.

A ver que tal va la cosa, yo seguiré comentando el código porque soy bastante patoso y después no me acuerdo ni de cómo hice algo o porqué.
Gracias.

[necro_vampire]

Son utiles los comentarios aunq sean pocos...
mas si el codigo es inmenso y los nombres de las variables son abreviaturas...

me pasaba que revisaba codigo q escribi hace tiempo y cmo staban las variables con nombre abreviados no entendia bien para que servian...
ahora escribo el nombre completo de las variables, procesos, funciones,etc
no es un comentario pero es util...

la verdad nunca probe eso de comentar primero y hacer el codigo despues, puede q sea util lo probare...
aunq me rekuerda un poco a TDD (Test Drive-Development)
por ejemplo si una funcion debe debolver un 1, se lo pone q retorne (return 1) ese valor...
despues al integrarlo y q funcione bien lo demas, se le da en comportamiento(se ace cmo deberia ser) para que devuelva el 1

[Kel]

hay algo parecido a lo que dices necro en el sentido más de escribir y modificar después, PDL (Pseudo Design language) http://en.wikipedia.org/wiki/Program_Design_Language

Se basa en escribir en lenguaje humano el diseño y estructura y despues pasar a codificar. Por lo visto lo emplean mucho más de lo que parece...

pd: me puse a programar un poco más y he cogido el turbo y te olvidas de comentar xD comentaba al principio y despues como el codigo más tocho lo estoy haciendo dentro de procesos (por eso de dividir contra mas la tarea) pues me olvido de comentar así que debo recordarme que comentar es bueno!

[Dluk]

pd: me puse a programar un poco más y he cogido el turbo y te olvidas de comentar xD comentaba al principio y despues como el codigo más tocho lo estoy haciendo dentro de procesos (por eso de dividir contra mas la tarea) pues me olvido de comentar así que debo recordarme que comentar es bueno!

Eso es lo que me pasa a mí. Siempre tengo la intención de comentar, pero después me agarra una especie de "modo Fórmula 1" y empiezo a escribir rápido lo que tengo en mente, olvidando comentar. Como dije antes, no sé si eso es bueno o malo.

[Kel]

Imagino que a la larga debe ser malo, porque coger un código de 5000 lineas y no entender el 40% porque no te acuerdas porque tal o cual variable hacia tal cosa debe ser un poco... depresivo xd y después ponte a revisar y ver porque funciona así.

Ahora mismo me pongo a comentar los procesos

[Dluk]

Imagino que a la larga debe ser malo, porque coger un código de 5000 lineas y no entender el 40% porque no te acuerdas porque tal o cual variable hacia tal cosa debe ser un poco... depresivo xd y después ponte a revisar y ver porque funciona así.

Hasta ahora, nunca me paso, y eso que el SD Smash Battle tiene 32033 líneas de código y el Megaman XS 11894.

Realmente, para entender todo, yo establezco estándares al programar:

1) Las variables tienen que tener todas nombres coherentes. Ponerle a una variable que actua como contador de gravedad la etiqueta "hola", logra que en un futuro no se tenga idea de para que era.

2) Todos los bucles los escribo en mayúsculas. Con eso los identifico perfectamente.

3) Tabulo todo. Lo que está adentro de un IF, lo tabulo para que se note que queda "adentro", como se puede ver en el extracto que puse más arriba. Todo lo que esté "anidado" dentro de algo, lo tabulo, aunque sean 20 IF y me quede algo que se salga de pantalla, de todas formas lo hago.

4) Evito meter muchas cosas en una misma línea. A todo le dedico su "Enter", je.

5) Comento el inicio de ciertos bloques y, si son muy largos, el final también.

Respetando todo lo que puse arriba, rara vez me pasa que no entiendo o no encuentro X parte del código. Igual eso no quiere decir que esto funcione con cualquier persona, a mi me sirve, pero cada cual tiene su forma de escribir...

Saludos

[Kel]

Interesantes consejos, los tendré en cuenta yo que soy un newbie
Gracias.

[Spiderman]

... He estado mirando el codigo de Daniel Navarro en los ejemplos... y todos sus juegos son comentados totalmente no se salta ni una línea y esto me hace pensar que estaría acostumbrado a comentar sus programas.

Pues me ha surgido esa duda, he leido en algún sitio que comentar antes de "codificar" ayuda al lado lógico mental, y por tanto es mejor comentar primero y despues pasar al "lenguaje", asi tienes mas o menos la idea sobre lo que quieres hacer. Lanzarse a programar de golpe y porrazo, para los que estén acostumbrados pues puede ser facil, pero que opinais sobre el tema de comentarios, ayudan o son simples recordatorios?

A mi me pasa como a mucha gente de aqui. Llevaba años sin hacer nada, pero nada nada. Ahora lo he retomado y me esta costando mucho sacar adelante el juego más simple que os podáis imaginar. Lo único que estoy haciendo ahora es reescribir un pequeño juego que hice en FENIX. No son muchas líneas de código, pero si supieras lo que he agradecido los comentarios que tenía puestos anteriormente. Me están facilitando el trabajo mucho. De hecho creo que sin esos comentarios debería empezar el programa desde cero. Sobre el método que comentas, croe que es muy práctico y recomendable hacerlo así, de golpe y porrazo como tu dices seguro que se pierde mucho tiempo y vista delante del ordenador. Y si ya mencionas que Daniel Navarro trabaja así... pues creo que no hay mucho más que decir. Aunque a lo mejor tanto comentario era para que entendieramos mejor los ejemplos. Igual te has preguntado como este chico era capaz de hacer tantas cosas y tan bien. La respuesta puede ser, que además de tener talento es un tio organizado. A mi parecer, todo un modelo a seguir para los que sean jovenes y se inicien en esto. ¿No crees?