Me he encontrado con este lenguaje de programación recientemente:

const float Zero = 0.0;

que luego se usa en las comparaciones:

if (x > Zero) {..}

¿Alguien puede explicar si esto es realmente más eficiente, legible o mantenible que:

if (x > 0.0) {..}

NOTA: Puedo pensar en otras razones para definir esta constante, solo me pregunto sobre su uso en este contexto.

Los posibles motivos son el almacenamiento en caché, el nombre o el tipo de forzamiento

Almacenamiento en caché (no aplicable)

Desea evitar el costo de crear un objeto durante el acto de comparación. En Java, un ejemplo sería

BigDecimal zero = new BigDecimal ("0.0");

Esto implica un proceso de creación bastante pesado y se sirve mejor utilizando el método estático proporcionado:

BigDecimal zero = BigDecimal.ZERO;

Esto permite comparaciones sin incurrir en un costo repetido de creación, ya que la JVM almacena en caché previamente el BigDecimal durante la inicialización.

En el caso de lo que ha descrito, un primitivo está realizando el mismo trabajo. Esto es en gran medida redundante en términos de almacenamiento en caché y rendimiento.

Nombramiento (poco probable)

El desarrollador original está intentando proporcionar una convención de nomenclatura uniforme para valores comunes en todo el sistema. Esto tiene algún mérito, especialmente con valores poco comunes, pero algo tan básico como cero solo vale la pena en el caso del caso de almacenamiento en caché anterior.

Tipo de forzamiento (lo más probable)

El desarrollador original está intentando forzar un tipo primitivo particular para garantizar que las comparaciones se emitan a su tipo correcto y posiblemente a una escala particular (número de lugares decimales). Esto está bien, pero el nombre simple "cero" probablemente sea un detalle insuficiente para este caso de uso con ZERO_1DP como una expresión más apropiada de la intención.

Es por "molestar a las herramientas"

Una posible razón que no veo en la lista aquí es porque muchas herramientas de calidad señalan el uso de números mágicos . A menudo es una mala práctica tener números mágicos en un algoritmo sin hacerlos claramente visibles para un cambio posterior, especialmente si están duplicados en varios lugares del código.

Por lo tanto, si bien estas herramientas tienen razón al señalar estos problemas, a menudo generan falsos positivos para situaciones en las que estos valores son inofensivos y es más probable que sean estáticos o simplemente sean valores de inicialización.

Y cuando eso sucede, a veces te enfrentas a la elección de:

• marcarlos como falsos positivos, si la herramienta lo permite (generalmente con un comentario con formato especial, lo cual es molesto para las personas que NO usan la herramienta)
• o extraer estos valores a constantes, si importa o no.

Sobre rendimiento

Depende del lenguaje, supongo, pero esto es bastante común en Java y no tiene ningún impacto en el rendimiento, ya que los valores están en línea en el momento de la compilación si son constantes reales static final. No tendría un impacto en C o C ++ si se declaran como constantes o incluso como macros de preprocesador.

Esto puede tener sentido ya que define explícitamente Zeroque es de tipo float.

Al menos en C y C ++, el valor 0.0es de tipo double, mientras que el equivalente floates 0.0f. Por lo tanto, asumir xque comparas también es siempre un floatdicho

x > 0.0

mientras que en realidad promueve xpara doubleque coincida con el tipo de lo 0.0que podría conducir a problemas (especialmente con pruebas de igualdad) La comparación sin conversión sería, por supuesto,

x > 0.0f

que hace lo mismo que

float Zero = 0.0; // double 0.0 converted to float  
x > Zero

Sin embargo, creo que sería mucho más útil habilitar advertencias de conversiones en el compilador en lugar de hacer que los usuarios escriban código incómodo.

En primer lugar, aquí cero se define como float, no int. Por supuesto, esto no afecta nada en la comparación, pero en otros casos cuando se usa esta constante, puede hacer la diferencia.

No veo otra razón por la cual Zerose declara una constante aquí. Es solo un estilo de codificación, y es mejor seguir el estilo si se usa en cualquier otro lugar de ese programa.

Es casi seguro que sea exactamente eficiente durante la ejecución (a menos que su compilador sea muy primitivo) y muy ligeramente menos eficiente durante la compilación.

En cuanto a si eso es más legible que x > 0... recuerde que hay personas que honestamente, genuinamente, piensan que COBOL fue una gran idea y un placer trabajar con ellos, y luego hay personas que piensan exactamente lo mismo sobre C. (El rumor ha ¡es que incluso existen algunos programadores con la misma opinión sobre C ++!) En otras palabras, no vas a llegar a un acuerdo general sobre este punto, y probablemente no valga la pena pelear.

[es] esto es realmente más eficiente, legible o mantenible que:

if (x > 0.0) {..}

Si estaba escribiendo código genérico (es decir, no específico del tipo), entonces muy posiblemente. Una zero()función podría aplicarse a cualquier tipo algebraico, o cualquier tipo que sea una adición de grupo wrt. Podría ser un número entero, podría ser un valor de coma flotante, incluso podría ser una función si su variable es, por ejemplo, una función dentro de un espacio lineal (por ejemplo, x es una función lineal de la forma z -> a_x * z + b_x) y luego zero()proporciona la función con a y b siendo ambos zero()del tipo subyacente.

Por lo tanto, esperaría dicho código en, por ejemplo, C ++ posiblemente (aunque a zero()no es muy común AFAIK), o en Julia, y tal vez en otros idiomas.