Cuantos Warning y Hint tienen tus proyectos?

[dec]

Hola,

Personalmente, procuro eliminar todos los "hints" y "warnings" de mi código. Cuando digo que procuro hacerlo quiero decir que no los dejo pasar, vaya, que trabajo para eliminarlos y los mantengo a raya. Sin embargo, el código de terceros no lo trato de la misma manera, o sea, que si hago un "Build" de mis proyectos, este arrojará algunos "hints" y "warnings", a los que, directamente, no presto atención. La verdad sea dicha.

Este es el "Build" de mi proyecto "principal" ahora mismo:



P.D. Soy un mal compañero, puesto que, quizás no supiese solucionar errores en el código de terceros, pero, los "hints" y los "warnings" son otra cosa y muchas veces se trata de cosas tan triviales como variables declaradas y no utilizadas.

P.D.2. Echando un vistazo al "Build" anterior me encuentro con que la mayoría de "hints" y "warnings" se producen en código de la propia VCL que acompaña a Delphi XE2.

[pacopenin]

Tengo que reconocer que la mayoría de los hints y warnings, así como la mayoría de las 1.303.330 líneas corresponde a componentes, no a mi código. Este es el proyecto con el que ando ahora...

[dec]

Empezado por pacopenin

Tengo que reconocer que la mayoría de los hints y warnings, así como la mayoría de las 1.303.330 líneas corresponde a componentes, no a mi código. Este es el proyecto con el que ando ahora...

¡Ya salió el millón de líneas!

[Ñuño Martínez]

Sin hacer trampas:

guillermo@guillermo-desktop:~/Programación/juegos/goiching$ make
Green Onions - The I Ching Saga - 
fpc -Mobjfpc -gl -vh -vw -Sh -Si  -Fusrc/ -Fusrc/* -Fu/usr/lib64/lazarus/lcl/ -Fu/usr/lib64/lazarus/lcl/* -Fi/usr/lib64/lazarus/lcl/include -Fu/usr/lib64/lazarus/components/lazutils/ -FUobj/ src/goiching.pas -obin/goiching
Hint: Start of reading config file /etc/fpc.cfg
Hint: End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.0.0 [2015/12/05] for x86_64
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling src/goiching.pas
Compiling src/juego.pas
Compiling src/config.pas
Compiling src/juego.pas
Compiling src/datos.pas
Compiling ./src/mingro/mngbitmap.pas
Compiling ./src/mingro/mngdata.pas
Compiling ./src/mingro/mngcustapp.pas
mngcustapp.pas(101,22) Hint: Parameter "EventType" not used
mngcustapp.pas(101,51) Hint: Parameter "Msg" not used
mngcustapp.pas(336,6) Hint: "array of const" not yet supported inside inline procedure/function
mngcustapp.pas(336,6) Hint: Inlining disabled
Compiling src/juego.pas
Compiling ./src/mingro/mnggame.pas
Compiling ./src/mingro/mnginput.pas
mnginput.pas(97,33) Hint: Parameter "aPlayerId" not used
Compiling src/motor.pas
Compiling ./src/mingro/mngsprites.pas
Compiling src/fase1.pas
Compiling src/jugadores.pas
Compiling ./src/mingro/mngfsm.pas
Compiling src/fase2.pas
Compiling src/fase3.pas
Compiling src/ninjas.pas
Compiling src/fase4.pas
Compiling src/titulo.pas
Compiling src/menu.pas
datos.pas(185,5) Hint: Local const "BMP_IDOYA" is not used
datos.pas(186,5) Hint: Local const "BMP_EXPLOSION" is not used
datos.pas(187,5) Hint: Local const "BMP_ESTRELLA" is not used
Linking bin/goiching
/usr/bin/ld: aviso: bin/link.res contiene secciones de salida. ¿Olvidó -T?
7737 lines compiled, 0.9 sec
10 hint(s) issued
bin/goiching ready!
Finished Green Onions - The I Ching Saga
To create the documentation, run 'make docs'.

Los dos primero "hint" no sé por qué salen.

Luego hay varios de "parameter not used". Estos son de métodos virtuales o de respuestas a eventos. Los últimos "Local const" sí tienen delito. Debería eliminarlos, pero me da pereza.

Y ojo al mensajito este:

/usr/bin/ld: aviso: bin/link.res contiene secciones de salida. ¿Olvidó -T?

Apareció por primera vez en una de las actualizaciones de la versión 2 de Free Pascal, y recuerdo que corrieron ríos de bits en la lista de correos de FPC por su culpa. El problema está en el enlazador de GNU, y parece que hablaron entre ellos (fue la época en la que se les estuvo metiendo caña para que arreglaran el soporte a Pascal en el depurador GDB) pero al final lo dejaron como estaba.

[roman]

Empezado por dec

Sin embargo, el código de terceros no lo trato de la misma manera, o sea, que si hago un "Build" de mis proyectos, este arrojará algunos "hints" y "warnings", a los que, directamente, no presto atención. La verdad sea dicha.

Y tienes toda la razón. Sería casi imposible arreglar estas cosas de códigos de terceros. Aunque, en estos casos, lo ideal sería omitir el uso de estos componentes porque, a fin de cuentas, los riesgos potenciales que menciona Al siguen ahí.

LineComment Saludos

[roman]

Revisando este tema, he abierto un X proyecto y marcado ciertas casillas en las opciones de advertencias que estaban desmarcadas, y de 0 advertencias aparecieron 901 . Ok, ¿debería revisar cada una de estas 901 advertencias? La mayoría son de un código de terceros, pero, aún suponiendo que fueran mías, ¿debería revisarlas? Yo digo que no. ¿Alguien se anima a decir por qué no y de cuáles casillas hablo?

LineComment Saludos

[[AgustinOrtu]]

Empezado por roman

Revisando este tema, he abierto un X proyecto y marcado ciertas casillas en las opciones de advertencias que estaban desmarcadas, y de 0 advertencias aparecieron 901 . Ok, ¿debería revisar cada una de estas 901 advertencias? La mayoría son de un código de terceros, pero, aún suponiendo que fueran mías, ¿debería revisarlas? Yo digo que no. ¿Alguien se anima a decir por qué no y de cuáles casillas hablo?

Quiza son de las de conversion implicita de strings con potencial riesgo de perdida de datos (tengo unas cuantas de esas)

Saludos

[roman]

Empezado por AgustinOrtu

Quiza son de las de conversion implicita de strings con potencial riesgo de perdida de datos (tengo unas cuantas de esas)

Saludos

A los que me refiero son Unsafe code y Unsafe type que, ambos, se refieren a fin de cuentas a apuntadores o punteros. Y, la verdad, ¿cómo se tratan esos casos? ¿Cómo se deshace uno de esas advertencias? La misma ayuda dice:

You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory

De manera que la única forma de tratarlos es ocultando ls mensajes o no programando con apuntadores, que, en programas propios es factible pero muchas bibliotecas de componentes los usan.

LineComment Saludos

[[Al González]]

Agregaría que las advertencias que vienen desactivadas de fábrica, son en la práctica cosas que nos toca a nosotros decidir si queremos que verdaderamente sean advertencias (activándolas) o no tomarlas como tales (dejándolas inactivas). Personalmente no suelo cambiar esa parte de la configuración general predeterminada de los proyectos pero, si tuviera que hacerlo, vigilaría a las fieras que haya soltado.

Un saludo.

[roman]

Empezado por Al González

Agregaría que las advertencias que vienen desactivadas de fábrica

¡Ah! Es que, la verdad, no recordaba si esas advertencias venían desmarcadas, como dices, de fábrica, o lo había hecho yo. De hecho, tu aclaración me deja más tranquilo de saber que no afecta.

LineComment Saludos

[dec]

Hola,

Empezado por roman

Y tienes toda la razón. Sería casi imposible arreglar estas cosas de códigos de terceros. Aunque, en estos casos, lo ideal sería omitir el uso de estos componentes porque, a fin de cuentas, los riesgos potenciales que menciona Al siguen ahí.

LineComment Saludos

Hombre, también puede verse al contrario: puesto que se trata de "hints" y "warnings" tal vez hasta uno podría hacer algo. Y nunca está demás echar una mano a compañeros... y a uno mismo. Otra cosa es el código de la VCL, en el que, creo yo, no habría que meterse en este aspecto. Por lo demás, es muy complicado dejar de usar componentes de terceros, y, de hecho, Delphi perdería muchísimo sino fuera por dichos componentes de terceros.

[roman]

Empezado por dec

Hombre, también puede verse al contrario: puesto que se trata de "hints" y "warnings" tal vez hasta uno podría hacer algo. Y nunca está demás echar una mano a compañeros... y a uno mismo. Otra cosa es el código de la VCL, en el que, creo yo, no habría que meterse en este aspecto. Por lo demás, es muy complicado dejar de usar componentes de terceros, y, de hecho, Delphi perdería muchísimo sino fuera por dichos componentes de terceros.

Realistamente hablando, es muy dífícil ponerse a arreglar código de terceros teniendo que arreglar el propio. Así que, como labor altruista claro que es encomiable pero muchas veces impráctico. Por otro lado, no digo que haya que dejar de usar componentes de terceros, sólo evitar los que no se toman la molestia de revisar esas advertencias. (*)


(*) Aún así, los usamos.

LineComment Saludos

[dec]

Hola,

Empezado por roman

Realistamente hablando, es muy dífícil ponerse a arreglar código de terceros teniendo que arreglar el propio. Así que, como labor altruista claro que es encomiable pero muchas veces impráctico. Por otro lado, no digo que haya que dejar de usar componentes de terceros, sólo evitar los que no se toman la molestia de revisar esas advertencias. (*)


(*) Aún así, los usamos.

Pero eso es porque no todos estamos habituados a usar herramientas como GIT y GitHub, que, nos permiten añadir cambios en el código de otros de una forma relativamente sencilla. Tengamos en cuenta que muchas de estas "notas" y "advertencias" son casi todas "olvidos" como variables declaradas pero no usadas, etc.

Por otro lado y respecto a los componentes de terceros, creo que ahí sí que hay que ser realistas Román: sin componentes de terceros la mayor parte de mis proyectos no serían posibles. Por ejemplo, el "diseñador" de mi App Builder. Si yo hubiera tenido que hacer dicho componente todavía estaría liado con él...