Cuantos Warning y Hint tienen tus proyectos?

[[AgustinOrtu]]

Me parecio divertida la idea de que publicasemos en numeros cuantos Warnings y Hints arroja el compilador para nuestros proyectos

No vale hacer trampa

Empiezo yo mismo con algunos.. veamos:

- Proyecto principal, podria decirse que esta "terminado" en el sentido de que ya esta desplegado y en uso

# Warnings: 201
# Hints: 83
# Líneas de Código: ~360.000

- Proyecto principal #2, version "mini" del anterior

# Warnings: 0
# Hints: 1
# Líneas de Código: 42.000

- Proyecto secundario #1, sin terminar (y falta mucho!)

# Warnings: 3
# Hints: 8
# Líneas de Código: ~260.000

- Proyecto "personal", un pequeño reproductor de musica y sintonizador de radio (a este le falta tanto trabajo como la inversa del tiempo que le dedico )

# Warnings: 0
# Hints: 6
# Líneas de Código: ~3.800


Saludos

[[Al González]]

Hola Agustín.

Hints
------
Antes de poner una aplicación en producción, es deseable atender y resolver todos los consejos o comentarios (hints) que emite el compilador. Aunque yo no dejo ninguno pendiente, tampoco pasa nada grave si queda uno que otro por ahí, porque no repercuten en el funcionamiento. No obstante, debemos orientarnos a dejar cada vez menos situaciones de hints en el código, ya que de lo contrario contribuimos a ofuscar el código fuente.

Warnings
----------
Antes de poner una aplicación en producción, es indispensable atender y resolver todas y cada una de las advertencias (warnings) que emite el compilador. Me sentiría mal si entregara un ejecutable compilado con sólo una de ellas, aunque se tratase de una aplicación de uso interno. El problema está en que una advertencia es un riesgo potencial de mal funcionamiento, sea por no prever alguna situación actual de procesamiento o por legar código no muy bien revisado que a la siguiente modificación cause un error.

Como excepción, y tratándose de algo compilado por otras personas, suelo pasar por alto la advertencia "Unit XXX implicitly imported" que aparece al compilar un paquete cuyas unidades explícitamente agregadas dependen de otras que no están en un paquete requerido.

Por otro lado, hay ocasiones en que una rutina nos causa una advertencia, pero dicha rutina es pequeña, fácil de comprender y tenemos pleno control de lo que hace. En casos así, si a nuestro entender la advertencia está de más, hay un mecanismo formal (disponible para ciertas advertencias) con el cual podemos decirle al compilador: "Ey, sé lo que hago, me hago responsable". Tomo un ejemplo de mi código:

Código Delphi [-]
  { TghZeroton }

  { Public overridden class methods }

  {$Warn No_RetVal Off}
  Class Function TghZeroton.NewInstance :TObject;
  Begin
    ghRaiseNotInstantiate;  // This raises an ENoConstructException
  End;
  {$Warn No_RetVal On}

Un cordial saludo.

Al González.

[Casimiro Notevi]

Creo recordar que se puede configurar qué mensajes se desea que aparezca y cuáles se oculten. Y es algo que ha ido cambiando en las distintas versiones de Delphi.
Por lo que mostrar esa información sería una comparativa poco aclaratoria, ya que depende del delphi que tengamos cada uno y de la configuración, también, de cada uno.

[Ñuño Martínez]

Recordádmelo mañana. Acabo de terminar mi última creación hace unos pocos días, pero no lo tengo a mano ahora mismo. Alguno hay.

[roman]

No sé. Me extraña un poco este hilo. Hace mucho tiempo que no programo seriamente en delphi, salvo pequeños enmiendos a sistemas ya hechos. Pero no recuerdo que dejara warnings o hints sueltos. Si acaso -y los eliminaba en las opciones- quedaban los de Platform Specific, y eso muy justificado porque mis sistemas no tenían posibilidad alguna de ser multiplataforma (que en aquellos años sólo se referían a Kylix, qepd).

LineComment Saludos

[[AgustinOrtu]]

Saludos Al

Primero que nada gracias por compartir tu sabiduria

No me malinterpretes; se que los numeros de mi proyecto #1 dejan bastante que desear, pero, para defenderme un poco, quiero aclarar que con ese proyecto comence mis andanzas no solo en Delphi sino en la programacion; y luego tuve un gran problema: fue un exito

Luego se ve cierta evolucion y mejoria en los proyectos mas nuevos en los que presto especial atencion a los mensajes emitidos por el compilador, y ademas he aprendido a escribir codigo con mejor calidad de tal modo que es mucho menos frecuente que se produzcan warnings o hints; por lo menos eso me deja algo mas tranquilo

Por otra parte, no estaba al tanto de que habia "configuraciones" que permiten modificar los hint y warning emitidos por el compilador. Yo tengo todo por defecto

Ahora que reviso mas minuciosamente, me encuentro con una gran cantidad de Warnings que son algo "injustas" como las que comenta roman, por ejemplo la W1002 Symbol %s is specific to a platform

Luego tengo algunas como las que comentas tu, de las que son "controlables", digamos que no estan "del todo mal"

Por supuesto que hay otras que son muy pero muy graves y de las cuales me avergüenzo mucho y prefiero dejar a imaginacion del lector

--

Luego está esta realidad, en estos tiempos que corren, que los clientes siempre piden mas y mas y uno no tiene el tiempo, los dedos, las neuronas y los recursos que quisiera para escribir el software del cual estaría 100% satisfecho y orgulloso

Pero el principal problema con el que toca luchar es el famoso código legado, que es la categoria en la cual encaja este proyecto

Y como alguien ha dicho sabiamente alguna vez: Es mas facil escribir que leer

Sin más, queria comentarlo un poco a modo de humor porque como comenta Ñuño, puede que alguno se cuele por ahi

Un gran saludo

[[AgustinOrtu]]

Este articulo nos muestra una situacion muy trivial y comica; al mismo tiempo, vemos como hasta los hint pueden revelar errores

Un saludo

[Casimiro Notevi]

Y me he encontrado con hints y warnings que son imposibles de eliminar aunque el código esté bien.
Nunca me he fijado en esos mensajes, el único mensaje que me importa es el de errores
Pero así, a grosso modo, en un proyecto normal de unas 500 mil líneas, puede haber 100 hints y 50 warnings, más o menos.

[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.

[jhonny]

Empezado por AgustinOrtu

Este articulo nos muestra una situacion muy trivial y comica; al mismo tiempo, vemos como hasta los hint pueden revelar errores

Un saludo

jejejeje me sentí identificado.

[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

[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.

[[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 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

[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.