Cuantos Warning y Hint tienen tus proyectos?

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