Ogni numero nel codice è considerato un "numero magico"?

Quindi ogni numero nel codice che stiamo inviando a un metodo come argomento è considerato un numero magico? Per me non dovrebbe. Penso che se un certo numero è, diciamo che è per la lunghezza minima del nome utente e iniziamo a usare "6" nel codice ... quindi sì, abbiamo un problema di manutenzione e qui "6" è un numero magico .... ma se stiamo chiamando un metodo che uno dei suoi argomenti accetta un numero intero, ad esempio come l'ith membro di una raccolta e quindi passiamo "0" a quella chiamata del metodo, in questo caso non vedo che "0" come una magia numero. Cosa pensi?

Se il significato del numero è molto chiaro nel contesto, non penso che sia un problema di "numero magico".

Esempio: supponiamo che tu stia cercando di ottenere la sottostringa di una stringa, dall'inizio ad alcuni token e il codice è simile al seguente (linguaggio e libreria immaginari):

s := substring(big_string, 0, findFirstOccurence(SOME_TOKEN, big_string));

In questo contesto, il significato del numero 0 è abbastanza chiaro. Suppongo che potresti definirlo START_OF_SUBSTRINGe impostarlo su 0, ma in questo caso penso che sarebbe eccessivo (anche se sarebbe l'approccio corretto se sapessi che l'inizio della sottostringa potrebbe non essere 0, ma ciò dipende dalle specifiche di la tua situazione).

Un altro esempio potrebbe essere se stai cercando di determinare se un numero è pari o dispari. scrittura:

isEven := x % 2;

non è strano come:

TWO := 2;
isEven := x % TWO;

Test di numeri negativi come

MINUS_ONE := -1;
isNegativeInt := i <= MINUS_ONE;

mi sento anche strano per me, preferirei vedere

isNegativeInt := i <= -1;

bool hasApples = apples > 0;

È ovvio zero significa assenza. Trovo 0 più facile da capire di una variabile denominata "encyValue ".

for(int i=0; i < arr.length; i++)

È ovvio che 0 è la posizione iniziale. Sarei confuso da una variabile denominata "firstPosition". Una tale variabile mi farebbe meravigliare se la posizione iniziale potesse cambiare.

Vorrei suggerire tre fattori chiave per decidere se qualcosa dovrebbe essere una dichiarazione costante:

1. Il numero è qualcosa che è rappresentabile in modo preciso e conciso
2. Esistono scenari plausibili in cui il valore dovrebbe cambiare, ma il codice non dovrebbe essere riscritto
3. Qualcuno che vede il numero sarebbe in grado di riconoscerlo più rapidamente o meno rapidamente di qualcuno che vede una costante nominata

Qualcosa come pi dovrebbe probabilmente essere scritto come costante nominata, piuttosto che come un letterale numerico, poiché un letterale numerico può essere inutilmente prolisso, inutilmente impreciso o entrambi. Qualcosa di simile al numero di slot in una cache dovrebbe essere probabilmente una costante con nome (anche se vedi la nota sotto) per consentire la possibilità di espandere la cache senza dover modificare tutto il codice che la utilizza. Cose come i numeri "4", "28" e "29" nell'istruzione if ((year % 4)==0) FebruaryDays = 29; else FebruaryDays = 28;probabilmente non dovrebbero essere chiamati costanti, poiché l'espressione è quasi certamente più leggibile di if ((year % YearsBetweenLeapYears)==0) FebruaryDays = FebruaryDaysInLeapYear; else FebruaryDays = FebruaryDaysInNonLeapYear;. Tieni presente che i manutentori degli standard hanno indicato che la lunghezza di febbraio del 2100 in quell'anno non corrisponderà alla formula di cui sopra, impedimento alla corretta gestione di tali date (ovvero il codice non verrà attivato da overflow di numeri interi o altri problemi simili).

Un avvertimento importante con la regola n. 2 è che in alcuni casi il codice può fare affidamento su numeri hardcoded in un modo che non può essere prontamente rappresentato da una costante denominata. Ad esempio, un metodo che calcola un prodotto incrociato di due vettori passati come parametri discreti sarà significativo solo se utilizzato su vettori tridimensionali. Il numero richiesto di dimensioni non è un valore che potrebbe essere modificato in modo significativo senza riscrivere completamente la routine. Anche se si prevedeva una possibile necessità di calcolare il prodotto incrociato di tre vettori a 4 dimensioni, l'uso di una costante denominata per il valore "3" farebbe ben poco per rendere più semplice soddisfare tale esigenza.

Questo, come tutti i principi, è una questione di laurea. In generale, i letterali numerici nel codice sorgente sono più sospetti quanto più sono grandi. Una lunghezza massima come 10 o un indirizzo di memoria come 0x587FB0 sono ovviamente cattive pratiche - è quasi certo che prima o poi dovrai ripetere questi valori più di una volta, creando un rischio di incompatibilità e sottili errori introdotti in luoghi che non erano cambiato.

0 è all'altra estremità della scala; è ancora sospetto ma non altrettanto. Stai usando 0 come valore sentinella? Quindi dovresti probabilmente usare una costante simbolica, solo perché la costante può spiegare cosa significa. È un accordo culturale estremamente radicato come "0 significa completamento riuscito"? Questo è probabilmente OK. Significa "il primo oggetto in una collezione"? Potrebbe essere innocuo, ma se esiste un metodo alternativo come first()probabilmente lo preferirei.

Ogni numero senza nome che non è immediatamente evidente dal contesto è un numero magico. È un po 'sciocco definire numeri che abbiano un significato che è immediatamente evidente dal contesto.

In django (python web framework), posso definire alcuni campi del database con un numero non elaborato come:

firstname = models.CharField(max_length=40)
middlename = models.CharField(max_length=40)
lastname =  models.CharField(max_length=40) 

che è più chiaro (e la pratica consigliata ) di dire

MAX_LENGTH_NAME = 40
...
firstname = models.CharField(max_length=MAX_LENGTH_NAME)
middlename = models.CharField(max_length=MAX_LENGTH_NAME)
lastname =  models.CharField(max_length=MAX_LENGTH_NAME) 

poiché è improbabile che abbia mai bisogno di cambiare la lunghezza (e può sempre confrontare con max_lengthil campo). Se devo modificare la lunghezza del campo dopo aver inizialmente distribuito l'applicazione, devo cambiarlo esattamente in una posizione per campo nel mio codice django, quindi scrivere una migrazione per cambiare lo schema del DB. Se mai dovessi fare riferimento a max_lengthun campo definito di un tipo di oggetto, posso farlo direttamente - se quei campi stavano definendo una Personclasse, posso usare Person._meta.get_field('firstname').max_lengthper ottenere ilmax_lengthin uso (che è definito in un unico posto). Il fatto che lo stesso 40 sia stato utilizzato per più campi è irrilevante in quanto potrei volerli modificare in modo indipendente. La lunghezza del nome non dovrebbe mai dipendere dalla lunghezza del nome medio o del cognome; sono valori separati e possono cambiare indipendentemente.

Spesso gli indici di array possono usare numeri senza nome; come se avessi un file CSV di dati che volevo mettere in un dizionario Python, con il primo elemento nella riga come il dizionario keyche scriverei:

mydict = {}
for row in csv.reader(f):
    mydict[row[0]] = row[1:]

Sicuro che potrei nominare index_column = 0e fare qualcosa del tipo:

index_col = 0
mydict = {}
for row in csv.reader(f):
    mydict[row[index_col]] = row[:index_col] + row[index_col+1:]

o peggio definire after_index_col = index_col + 1per sbarazzarsi di index_col+1, ma ciò non rende il codice più chiaro a mio avviso. Inoltre, se do index_colun nome, farò meglio a far funzionare il codice anche se la colonna non è 0 (quindi la row[:index_col] +parte).