Non riesco a vedere il punto delle costanti. Ad esempio, posso utilizzare il famoso esempio di PI:
PI = float(3.14)
Qui ho finito il lavoro senza una costante. A chi importa se il valore non cambia mai durante la vita del programma o se è la migliore pratica.
Posso definire PI come variabile e ottenere lo stesso compito svolto altrettanto bene.
Concettualmente, le opzioni per assegnare un valore a una variabile o una costante differiscono solo in un modo: Un compilatore darebbe un avvertimento quando tenti di riassegnare una costante
Hai ragione. Se assegni il valore a una variabile anziché a una costante, il lavoro verrà eseguito fintanto che ti stai attento a non modificare il valore ad esso assegnato.
Potrebbe sembrare ridondante per te, ad esempio se stai facendo un programma per trovare l'area di un cerchio di un dato raggio, puoi scrivere
float pi = 3.14
float area (float r) :
return pi*r*r
e pensa a te stesso che se qualcuno dovesse cambiare il valore di pi in qualcos'altro come 2.5, allora sono davvero le vittime della loro stessa stupidità.
E nessuno vuole caricarsi di una funzionalità non necessaria.
Tuttavia, i programmatori tendono ad eliminare il maggior numero possibile di problemi futuri che possono. Può accadere che se il programma è grande e ci siano molti programmatori che lavorano su di esso, qualcuno può ridefinire la tua variabile (per farlo funzionare per loro) ma poi la chiamata successiva alla tua funzione che dipendeva dal valore corretto della tua variabile sarebbe quindi ritornata risultati errati.
Ora ci sono due modi per eliminare questa possibilità, o potresti rendere la tua variabile locale alla funzione stessa, ma ciò comporta ridondanza perché dovresti farlo per ogni funzione che fa riferimento ad essa.
Oppure potresti usare la bella funzionalità fornita dal linguaggio di programmazione e dichiarare il tuo valore una costante in modo che il compilatore possa dare un avvertimento se si tenta di riassegnare il valore della costante.
who cares if the value never changes during the lifetime of the program or it's programing best practise.
A chi importa? Persone che devono mantenere il tuo codice.
Che cosa succede se il project manager viene da te tra diversi mesi e dice che "3.14" non è più un'approssimazione sufficiente per pi per la tua applicazione? Vuole rendere il programma più accurato perché verrà utilizzato per costruire il prossimo space shuttle e ha bisogno di precisione fino a 8 decimali.
Che cosa fai? Basta fare una ricerca massiccia e sostituire "3.14" in "3.14159265" su tutto il codice del tuo progetto? Bene, congratulazioni. Ora hai incasinato un altro calcolo da qualche altra parte dove un altro programmatore geniale ha codificato il valore "23.14994". Ora quel valore è "23.14159265994" e lo space shuttle è appena esploso.
Le costanti aiutano a mantenere i valori coerenti dove ne hai bisogno. Certo, non ti aspetti che il tuo gioco di Tic-Tac-Toe abbia più di tre colonne e tre file, ma qualcuno potrebbe voler espandere il gioco a una griglia 5-5. Rende anche il tuo codice più leggibile. In futuro puoi anche rifattorizzare il tuo codice facendo clic con il pulsante destro del mouse su una variabile / costante e rinominandolo attraverso l'applicazione o il file.
EDIT: il titolo originale della domanda era "Perché abbiamo bisogno di costanti nella programmazione?" Poiché la domanda è stata modificata in "Perché non possiamo semplicemente utilizzare le variabili anziché le costanti?" Risponderò anche a questa domanda.
Le variabili possono cambiare. Le costanti non possono. Se qualcuno decide di avere solo due cifre di precisione e la tua variabile contiene 8 cifre di precisione, potrebbero troncare le cifre insignificanti dalla tua variabile. Sfortunatamente, ciò può causare problemi ad altre parti dell'app che fanno affidamento sul valore originale e più preciso. Rendendo il valore una costante, ciò comporterebbe un errore di compilazione e manterrebbe l'integrità dell'applicazione.
Nel tuo esempio, hai definito una variabile mutabile PI , che puoi fare riferimento nel tuo programma. Hai creato il codice DRY , che deve essere aggiornato in un unico posto solo se desideri modificarne la definizione. Questo è buono, e funziona per piccoli programmi dove c'è solo uno sviluppatore e non molto codice.
Man mano che la base di codice diventa più grande e man mano che sempre più persone iniziano a lavorare nel codice, diventa molto più importante comunicare l'intenzione .
Sebbene molte persone siano probabilmente consapevoli del fatto che Pi è una costante matematica e non si aspettano che cambi, lo stesso non è vero per le costanti più . Dichiarando qualcosa come una costante, stai dicendo ad altri sviluppatori (incluso il tuo futuro io) cosa significa quella costante.
Quando vedi che un valore è dichiarato come costante, il codice è che comunica le seguenti cose a te, come sviluppatore:
3.14 è un'approssimazione di Pi , ma molte costanti non hanno significato senza un nome. if (i > MaxNumberOfUsers) è molto più significativo di if (i > 10) . Dichiarare un valore come costante spesso dice anche al compilatore alcune cose (anche se varia a seconda della lingua e del compilatore):
Molti compilatori ottimizzeranno i valori costanti in fase di compilazione e inseriranno i loro risultati direttamente nel codice.
// No calculation will take place at runtime - all of these values
// can be replaced with their calculated results at compile time
const long BytesPerKilobyte = 1024;
const long BytesPerMegabyte = 1024 * BytesPerKilobyte; // Compiles as 1048576
const long BytesPerGigabyte = 1024 * BytesPerMegabyte; // Compiles as 1073741824
// ... elsewhere in the code ...
const long maxFileSize = BytesPerMegabyte * 40;
if (fileSize > maxFileSize) // actually compiles to 'if (fileSize > 41943040) {...}'
{
println("The file is too large to work with");
}
Quando ho iniziato a imparare a programmare non ho capito il punto delle costanti. Non avevo mai lavorato a un progetto con più di qualche lezione, ed era facile mantenere tutto in ordine.
La maggior parte del codice non è così. La maggior parte del codice esiste in ambienti molto grandi, essendo gestiti da più persone, in momenti diversi. Man mano che i progetti su cui lavori crescono, diventa sempre più importante essere in grado di comunicare agli altri sviluppatori e a te stesso ciò che il tuo codice è destinato a fare.
In questo tipo di ambienti, apprezzerai qualsiasi cosa che porti via parte del carico mentale che ti viene fornito mantenendo tutto nella tua testa.
Man mano che i progetti diventano sempre più grandi, diventano sempre più difficili da mantenere, principalmente perché la mente umana è limitato nel numero di cose che può conservare nel suo contesto immediato . Per ovviare a questo, di solito vogliamo rompere il progetto in componenti più piccoli e più semplici, in modo che possiamo lavorare su un componente senza dover tenere conto di come funzionano gli altri componenti. Anche se usiamo altri componenti, vorremmo utilizzarli come scatole nere in modo da rimanere concentrati sul componente su cui stiamo lavorando attualmente.
Molte tecniche, strumenti, librerie e funzioni del linguaggio di programmazione sono dedicate ad aiutarci a rompere i nostri progetti in componenti più facili da lavorare. Uno dei principi per chiarire quale parte del codice è responsabile di cosa.
Di solito, vuoi che la dichiarazione delle cose (variabili, costanti, classi, funzioni, ecc.) sia responsabile della definizione di ciò che la cosa può e non può fare, ed è molto utile avere i tuoi strumenti in modo intelligente avvisarti quando usi male quella cosa. Quando chiami sqrt(-18) , è bello avere un errore di compilazione che dice "non puoi chiamare sqrt con un numero negativo!". È meno bello, ma comunque buono, avere questo errore in fase di esecuzione. Davvero non vuoi ottenere qualche risultato strano più in basso perché sqrt(-18) ha restituito un valore casuale perché lo hai usato in modo errato ...
Questo è il punto in cui si inseriscono le costanti. Ti permettono di definire alla dichiarazione che il valore non debba essere modificato in fase di runtime e tale definizione sia applicata durante l'utilizzo . Quindi se alcuni sviluppatori pensano di poter cambiare il loro valore - il compilatore li urlerà.
Ora, nessuno di coloro che hanno ragione cambierebbe il valore di PI , ma altri valori potrebbero apparire modificabili anche quando non lo sono. Rendendoli costanti significa che il loro manutentore non supporterà le implicazioni di modificarli in fase di runtime e proibirà ad altri sviluppatori di modificarli.
BTW - Continuo a fare riferimento a "questo sviluppatore" e "altro sviluppatore", ma possono essere lo stesso sviluppatore. Dal momento che non puoi mantenere l'intera struttura del programma nella tua mente umana limitata, quando lavori su un altro componente potresti anche essere un altro sviluppatore perché hai cambiato il tuo contesto.
Uno dei motivi principali per le costanti (in particolare le costanti del compilatore) è di dare un valore coerente per una cosa predefinita (cioè, pi, e, null, ecc.).
Le costanti consentono anche di risparmiare tempo. Non devo cercare i valori quando ho bisogno di eseguire determinati tipi di matematica.
In alcuni linguaggi di programmazione chiamare qualcosa di costante è un modo per contrassegnarlo come immutabile. Usando il tuo esempio di PI puoi definire una variabile chiamata PI e assegnarla a 3.14 e usarla in tutto il codice come valore di PI. Tuttavia, cosa succede quando un programmatore successivo che usa il tuo codice decide che il loro codice ha bisogno di una rappresentazione più precisa di PI e impostano la tua variabile PI su 3.141592. Questo NON POTREBBE causare un problema se il tuo codice esistente può gestire la precisione aggiunta o potrebbe spezzare tutto in un modo strano come arrotondarlo a 3.1416 (che è sicuramente NON PI).
Per espandere la risposta @Robert Harveys
Leggi altre domande sui tag programming-languages c#