I possibili motivi sono il tipo di cache, denominazione o forzatura

Caching (non applicabile)

Vuoi evitare il costo della creazione di un oggetto durante l'atto di confronto. In Java un esempio sarebbe

BigDecimal zero = new BigDecimal ("0.0");

questo comporta un processo di creazione abbastanza pesante e viene offerto meglio utilizzando il metodo statico fornito:

BigDecimal zero = BigDecimal.ZERO;

Questo consente confronti senza incorrere in costi di creazione ripetuti poiché il BigDecimal viene precaricato dalla JVM durante l'inizializzazione.

Nel caso di ciò che hai descritto, un primitivo sta eseguendo lo stesso lavoro. Questo è ampiamente ridondante in termini di memorizzazione nella cache e prestazioni.

Assegnazione di nomi (improbabile)

Lo sviluppatore originale sta tentando di fornire una convenzione di denominazione uniforme per i valori comuni in tutto il sistema. Questo ha qualche merito, in particolare con valori non comuni, ma qualcosa di fondamentale come zero vale solo per il caso di memorizzazione nella cache precedente.

Tipo forzato (molto probabilmente)

Lo sviluppatore originale sta tentando di forzare un particolare tipo primitivo per garantire che i confronti siano espressi nel loro tipo corretto e possibilmente su una scala particolare (numero di posizioni decimali). Questo è OK, ma il nome semplice "zero" è probabilmente un dettaglio insufficiente per questo caso d'uso, poiché ZERO_1DP è un'espressione più appropriata dell'intenzione.

È a causa di "Naging degli strumenti"

Una possibile ragione per cui non vedo elencato qui è perché molti strumenti di qualità segnalano l'uso di numeri magici . Spesso è una cattiva pratica avere numeri magici lanciati in un algoritmo senza renderli chiaramente visibili per modifiche successive, specialmente se sono duplicati in più punti del codice.

Quindi, mentre questi strumenti hanno ragione nel segnalare questi problemi, spesso generano falsi positivi per situazioni in cui questi valori sono innocui e molto probabilmente statici, o semplicemente valori di inizializzazione.

E quando ciò accade, a volte devi affrontare la scelta di:

• contrassegnandoli come falsi positivi, se lo strumento lo consente (di solito con un commento appositamente formattato, che è fastidioso per le persone che NON usano lo strumento)
• o estraendo questi valori alle costanti, che siano importanti o meno.

Informazioni sulle prestazioni

Dipende dal linguaggio che presumo, ma questo è abbastanza comune in Java e non ha alcun impatto sulle prestazioni, poiché i valori sono in linea in fase di compilazione se sono costanti reali static final . Non avrebbe un impatto in C o C ++ se sono dichiarati come costanti o anche come macro pre-processore.

Questo potrebbe avere senso poiché definisce esplicitamente Zero come di tipo float .

Almeno in C e C ++ il valore 0.0 è di tipo double , mentre l'equivalente float è 0.0f . Pertanto, supponendo che x confronti sia sempre un float che dice

x > 0.0

mentre in realtà promuovi x in double per abbinare il tipo di 0.0 che potrebbe portare a problemi (con test di uguaglianza in particolare). Il confronto senza conversione sarebbe ovviamente

x > 0.0f

che fa lo stesso di

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

Tuttavia, penso che sarebbe molto più utile abilitare gli avvisi di conversione nel compilatore invece di fare in modo che gli utenti scrivano codice scomodo.

Innanzitutto, qui zero è definito come float , non int . Ovviamente, questo non influisce su nulla nel confronto, ma in altri casi quando viene usata questa costante, potrebbe fare la differenza.

Non vedo altri motivi per cui Zero è dichiarato una costante qui. È solo uno stile di codifica, ed è meglio seguire lo stile se viene usato ovunque in quel determinato programma.

È quasi certamente altrettanto efficiente durante l'esecuzione (a meno che il compilatore non sia molto primitivo) e leggermente meno efficiente durante la compilazione.

Per sapere se è più leggibile di x > 0 ... ricorda che ci sono persone che onestamente, sinceramente, pensano che COBOL sia stata una grande idea e un piacere lavorare - e poi ci sono persone che pensano esattamente la stessa cosa circa C. (Si dice che esistano persino programmatori con la stessa opinione su C ++!) In altre parole, si è non in procinto di ottenere un accordo generale su questo punto, e probabilmente non vale la pena combattere sopra.

[is] this is really any more efficient or readable or maintainable than:

if (x > 0.0) {..}

Se stavi scrivendo il codice generico (cioè non specifico del testo), allora molto probabilmente. Una funzione zero() può essere applicata a qualsiasi tipo algebrico o qualsiasi tipo che sia un gruppo w.r.t. Inoltre. Potrebbe essere un numero intero, potrebbe essere un valore in virgola mobile, potrebbe anche essere una funzione se la variabile è, diciamo, essa stessa una funzione all'interno di uno spazio lineare (ad esempio x è una funzione lineare della forma z - > a_x * z + b_x) e quindi zero() fornisce la funzione con a e b essendo entrambi zero() del tipo sottostante.

Quindi ti aspetteresti che tale codice sia, diciamo, C ++ (anche se un zero() non è molto comune AFAIK), o in Julia, e forse in altre lingue.