Dichiarare le variabili

Question

Supponi di avere una variabile chiamata hotelPropertyNumber . Il contenuto sarà sempre un numero ma normalmente verrà utilizzato come stringa. Ci sarebbe qualcosa di "sbagliato"? dichiarandolo come una stringa in modo da non doverlo convertire continuamente in una stringa .... o è una cattiva abitudine di programmazione?

Grazie.

Answer 1

Un numero è un oggetto matematico utilizzato nel conteggio e nella misurazione. Se usi il tuo hotelPropertyNumber per il conteggio, vale a dire applicare qualsiasi operazione aritmetica, esso è numero e deve essere memorizzato come tipo numerico.

In caso contrario, non è un numero; è una stringa.

Answer 2

In alcune lingue puoi creare un tipo definito dall'utente come " class HotelPropertyNumber " ;, che:

• Supporta esattamente i metodi necessari
• Può archiviare i suoi dati internamente come una stringa
• Può confermare (nel suo costruttore) che il suo valore ha una sintassi simile al numero
• Non può essere confuso con altre istanze di numero e / o tipo stringa che non sono istanze HotelPropertyNumber.

Answer 3

Conserva sempre le tue informazioni nella sua forma più semplice. In questo caso, un numero intero. Convertilo in una stringa quando necessario. Quasi tutte le lingue lo rendono quasi indolore, specialmente per un numero intero di una stringa.

Un buon esempio di questo è stato nel StackOverflow Podcast # 58 , quando Jeff memorizzato l'HTML del titolo nel database e non solo il titolo da solo. Ciò ha causato molti problemi quando voleva aggiungere funzionalità in un secondo momento e visualizzare quel titolo in cui non era necessario HTML.

ChrisW evidenzia inoltre che affermando ciò, type safety . Ho pensato che fosse abbastanza importante da notare.

Answer 4

Dipende da cosa vuoi fare con loro.

Probabilmente non eseguirai mai l'aritmetica su di loro, ma che ne dici di ordinare? I numeri interi verranno ordinati in modo diverso rispetto alle stringhe. Vuoi che siano 1, 10, 2, ecc.? In caso contrario, utilizzare numeri interi o un metodo di ordinamento speciale.

D'altra parte, l'uso delle stringhe consentirà più tipi di "numeri" dopo. "10090A", per esempio. E non ci saranno problemi con l'overflow come può succedere con gli interi.

Answer 5

Igor Krovokon l'ha già detto, ma volevo elaborarlo un po '.

Perché pensi che il contenuto di un numero di hotel sia un numero? & Quot; 12 " non è un numero. È una stringa contenente un paio di cifre. Non puoi prendere la radice quadrata della stanza # 153, ma puoi farlo con il numero 153.

Un numero di camera d'albergo non si comporta come numero. Un numero è un concetto matematico e può essere rappresentato testualmente in molti modi diversi. 14 potrebbe essere scritto come XIV in numeri romani, "quattordici", o 0xfe in esadecimale, o 11111110 in binario. Ma è probabile che lo staff dell'hotel ti dia uno sguardo molto strano se chiedi la camera uno-uno-uno-uno-uno-uno-zero. & Quot;

I numeri delle camere d'albergo non sono numeri matematici, quindi non dovrebbero essere rappresentati come numeri interi.

Sono quindi stringhe? Sì, più o meno, ma hanno alcuni vincoli aggiuntivi, come hai notato.

Non ogni stringa è un numero hotel valido. & Quot; 14 " è buono, ma "Anguria" non lo è.

Quindi, idealmente, dovrebbe essere rappresentato come un tipo di dati astratto che avvolge una stringa e garantisce che nella stringa non siano presenti non cifre.

In pratica, ovviamente, è improbabile che si verifichino molti problemi se si prende la via d'uscita semplice e si rappresentano i numeri delle stanze come ints o stringhe. Ma il miglior design sarebbe quello che garantiva che i numeri delle stanze si comportassero come numeri delle stanze. Né le stringhe né gli ints lo fanno.

Answer 6

Sono d'accordo con @Eric. Scoprirai che se lo dichiari come stringa, commetterai degli errori analizzandolo come int o applicandolo come int. Basta usare un int.

Answer 7

No, non necessariamente sbagliato. Ma potresti considerare di rinominare la variabile per riflettere che si tratta di una stringa. Non penso che ci sia una semplice risposta alla necessità di tenerlo un numero o convertirlo in una stringa. Dipende dalla situazione. Se scegli di memorizzarlo come numero intero nella tua applicazione e devi convertirlo in una stringa 1000 volte nel tuo codice, allora varrebbe la pena eseguire la conversione in una stringa una volta. Dovresti considerare i compromessi in base alla situazione.

Answer 8

Non sono d'accordo con Eric.

Non ci sono " Sempre " regole in fase di sviluppo.

Se stai usando questa variabile principalmente come stringa, allora ha più senso memorizzarla come stringa e perdere il "numero" " dal nome della variabile.

Se stai eseguendo più operazioni numeriche su questa variabile, allora è un numero e dovrebbe essere memorizzato come valore numerico e convertito una stringa da usare come stringa.

Answer 9

Avrebbe senso cambiare il nome in hotelPropertyIdentifier? Ciò potrebbe evitare tutte le connotazioni di chiamare un numero.

Answer 10

Puoi sempre rendere pubblico " HotelPropertyNumber () " funzione che restituisce il numero come una stringa, ma int è ancora mantenuto sotto le copertine.

Se decidi di non aver davvero bisogno dell'int sotto le copertine, HotelPropertyNumber () può semplicemente restituire la stringa privata.

Answer 11

Non dire mai sempre. Potrebbe non essere sempre rappresentato da cifre. 14 può, ad esempio, essere suddiviso in 14a e 14b. Oppure 21 e 22 possono essere uniti in 21-22. È più probabile che fare l'aritmetica con loro.

Guarda gli indirizzi, che di solito iniziano con l'intenzione di essere numerici. (Anche un'analogia piuttosto stretta.)

Answer 12

Non è un'abitudine cattiva di per sé, ma potrebbe causare problemi in seguito.

Parlando ora per esperienza personale: ero un grande fan della memorizzazione di valori numerici che sarebbero sempre stati usati come stringa nelle variabili stringa. Voglio dire, perché no, giusto? Ti salva tutto quel noioso casting e quant'altro, e puoi andare avanti con la vera carne del problema. (Che, ovviamente, sta decidendo cosa ordinare per pranzo.)

Quindi, ho trascorso la maggior parte della giornata cercando di capire perché il sistema live stava lanciando ogni tipo di folle eccezione. Si scopre che " 1 " Stavo guardando nei dati era davvero un minuscolo "l".

E poi, come si suol dire, sono diventato illuminato.

(Naturalmente, questo può davvero cambiare in base alla lingua in cui ti trovi. In qualcosa come Java, alcune righe degne di definizione di classe risolvono tutti questi problemi. In Python o Perl, la domanda non significa nemmeno nulla - la lingua è "corretta". Bene, per qualche definizione di "giusta", comunque.)