Devo dichiarare la variabile solo come numero intero se posso eseguire calcoli su di essa?

Dovresti scegliere un intero su stringa se i valori un intero può avere e le operazioni un supporto intero sono più adatte per i dati in questione rispetto ai valori e alle operazioni di una stringa.

Va bene se alcuni dei valori / operazioni di quel tipo non hanno senso per quei dati, semplicemente perché ci sono così tanti diversi tipi di dati del mondo reale che se provassimo a fare in modo che tutti i database e i linguaggi di programmazione abbiano tipi integrati separati che si abbinino perfettamente a loro, non faremmo mai un vero lavoro.

Innanzitutto, gli indirizzi IP. Assumendo per semplicità ci preoccupiamo solo degli indirizzi IPv4, quindi RFC 760 dice "Gli indirizzi sono a lunghezza fissa di quattro ottetti (32 bit) ". Questo ci dice immediatamente che l'insieme di valori possibili per un intero senza segno a 32 bit è esattamente uguale all'insieme di indirizzi IP validi . In linea di principio, una rappresentazione a stringa consentirebbe tutti i tipi di indirizzi IP chiaramente non validi come "9999.9999.9999.-42e5" e "Hello World!" a meno che non scriviamo un gruppo di codice di convalida. Questa è la ragione più che sufficiente per utilizzare gli interi come rappresentazione "back-end" degli indirizzi IP, anche se il resto del codice preferisce utilizzare una stringa o qualche oggetto con un metodo di stampa abbastanza per garantire che si ottenga normalmente il "punto decimale" "La notazione degli umani piace. Se è richiesto un altro argomento, si noti che una parte del motivo della notazione decimale punto per gli indirizzi IP è così comune che i quattro componenti a 8 bit di un indirizzo IP hanno spesso significati separati. Quindi, probabilmente vorremmo estrarre quei quattro numeri a 8 bit separati da un indirizzo IP di volta in volta, e prendere il primo o l'ultimo 8 bit di un intero a 32 bit è un'operazione molto più semplice e veloce di tokenizing a string .

Quindi abbiamo numeri di porta. I protocolli TCP e UDP definiscono una porta come un numero intero senza segno a 16 bit , quindi, ancora una volta, più o meno lo stabilirà. Ma un altro argomento che si applica alle porte è che ci sono molti "range" importanti di porte, come da 0 a 1023 che sono le "porte conosciute" usate dai processi di sistema, e questi intervalli sono chiaramente definiti con l'ordinamento intero in mente piuttosto che ordinare stringhe . Nessuno sano di mente affermerebbe che la porta 50 non rientra nell'intervallo delle porte conosciute solo perché la stringa "50" è maggiore della stringa "1023".

Noterai che in entrambi questi esempi non ho descritto alcun "calcolo" come addizione o sottrazione, quindi la risposta letterale alla tua domanda è "no". Non conosco nessuna situazione in cui avrebbe senso aggiungere due indirizzi IP o numeri di porta. Ancora una volta, la maggior parte dei dati del mondo reale non sarà mai adatta perfetta per qualsiasi tipo che diamo.

E poiché ho sostenuto "interi" su entrambi gli esempi, includo alcuni controesempi: numeri di telefono e indirizzi. Per gli indirizzi stradali probabilmente non ho nemmeno bisogno di argomentare; è così ovvio che nessun tipo numerico potrebbe mai sperare di rappresentare adeguatamente quel tipo di informazione. Per i numeri di telefono è meno ovvio, ma considera quanto segue: la lunghezza di un numero di telefono varia in base al paese; la lunghezza è sempre misurata in cifre, non in bit / byte / ottetti; vari simboli come +, # e () sono talvolta usati per rappresentare informazioni importanti come codici di paesi e prefissi; Non riesco a pensare a nessun motivo per aggiungere, sottrarre o confrontare due numeri di telefono; estrarre un codice paese o prefisso da un numero di telefono completo è un vero problema di tokenizzazione delle stringhe che non possiamo ridurre a un'operazione di cambio di bit perché tutte le suddette hanno lunghezze variabili.

Quando scegli un tipo, pensa a:

1. Come viene usata la variabile,
2. Quali sono i valori validi / non validi, se pertinenti,
3. Come e dove è memorizzata la variabile ed è importante l'archiviazione efficiente.

Esempio di un indirizzo IPv4 che usi per filtrare le richieste HTTP da macchine indesiderate:

1. L'IP verrà utilizzato per abbinarlo con un intervallo di indirizzi IP,
2. Ogni parte deve essere compresa tra 0 e 255,
3. N / A.

Considerati i primi due punti, una serie di quattro byte sembra una buona scelta.

Esempio di un indirizzo IPv4 archiviato nei registri di controllo (formato syslog):

1. L'indirizzo IP sarà convertito in testo,
2. L'IP proviene da una fonte attendibile (il framework utilizzato dalla tua applicazione che ti dà il numero IP del client); non è necessario un ulteriore sanitizzazione dei valori,
3. I dati sono memorizzati come una stringa.

Pertanto, un formato di stringa ( 192.168.1.5 ) sembra una buona scelta.

Esempio di un batch che elabora migliaia di indirizzi IPv4 al secondo, li confronta con una corrispondenza esatta e richiede la memorizzazione compatta di tali indirizzi:

1. L'indirizzo IP è abbinato ad altri valori. Non ci sono intervalli coinvolti, abbiamo solo bisogno di sapere se l'indirizzo A è esattamente uguale all'indirizzo B. Gli indirizzi raramente devono essere mostrati nel loro modulo 0.0.0.0 e vengono analizzati da questo modulo solo una volta.
2. Ogni parte deve essere compresa tra 0 e 255.
3. Lo storage efficiente è fondamentale.

Qui, un DWORD sembra un modo possibile per mantenere gli indirizzi. Rende complicato estrarre singole parti dell'indirizzo, ma dato l'utilizzo effettivo, non ne abbiamo necessariamente bisogno.

Lo stesso vale anche per altri tipi di dati. I numeri di telefono vengono solitamente memorizzati come stringhe perché consentono di gestire formati diversi ( +33 (0)6 12 34 56 78 ), poiché l'igienizzazione dei numeri di telefono si basa in genere su una stringa e perché l'efficienza di archiviazione non è importante.

Se memorizzi numeri di telefono nazionali con un formato noto e la convalida è importante e l'efficienza dello storage è importante (ad esempio se hai bisogno di trasferire migliaia di telefoni numeri attraverso una connessione internet lenta), memorizzare quei numeri come un numero potrebbe essere una soluzione.

Penso che la domanda possa essere applicata ai numeri in generale (e ad altri tipi di dati), non solo agli indirizzi IP e alle porte.

Anche se i numeri sono apparentemente solo cifre, come vengono visualizzati può variare considerevolmente. Un esempio comune sono i raggruppamenti di cifre. Un valore come 1999 è spesso visualizzato come 1,999 qui nel Regno Unito. Il modo in cui questo numero viene visualizzato altrove nel mondo è locale specifico .

Anche se non pianifichi mai di fare calcoli matematici su tali numeri, il fatto stesso che sia definito come un valore numerico alla fonte offre agli sviluppatori che vengono dopo di te un indizio sul tipo di informazione che può essere memorizzato in esso. Lo stesso vale per altri tipi di dati. Supponiamo che tu abbia un valore booleano che è stato memorizzato ovunque come stringa. Se uno sviluppatore ha riscontrato che mancavano i dati, potrebbe essere tentato di memorizzare il valore come "Sconosciuto" che è chiaramente oltre i limiti dei valori booleani validi.

Inoltre (tornando al tuo esempio di indirizzo IP), questo potrebbe essere sempre passato come una stringa, ma quando viene inserito, il fatto che conosci è composto da numeri lo rende più facile da convalidare alla fonte. Se la vista comune è sempre che questa è solo una stringa, allora c'è qualche ulteriore convalida da fare quando questo valore viene inserito nel sistema.

Quello che sto ottenendo è che mentre è importante presentare tali informazioni in un formato pratico, è anche importante che i dati grezzi siano archiviati in un formato concordato che sarà compreso in diversi sistemi, piattaforme, lingue e localizzazioni ove possibile.