Chiunque scriva buon codice sa che l'uso delle costanti è sicuramente auspicabile e io in questo non la penso certamente in modo diverso. In linea di massima le costanti pervadono il codice che scrivo e spesso ormai vi sono situazioni in cui viene automatico farne uso. Credo fermamente però, che vi siano situazioni nelle quali una costante non ha nessun significato; mi è capitato ad esempio di imbattermi in codice scritto da chi considera la "stringa", intesa come una valore costante hard-coded all'interno del codice, come una onta, un peccato originale da cui non si può essere assolti.

Vi sono situazioni in cui il è il contesto in cui viene usato che rende implicitamente un valore "costante" e quindi l'incapsularlo una volta in più non è giustificato. Vi faccio un esempio classico:

   1: public static string WorkingDirectory
   2: {
   3:     string workingDirectory = ConfigurationManager.AppSettings["WorkingDirectory"];
   4:  
   5:     if (string.IsNullOrEmpty(workingDirectory))
   6:         throw new ConfigurationErrorsException(Resources.WorkingDirectoryNotSpecified);
   7:  
   8:     return workingDirectory;
   9: }

In questo esempio l'uso di una stringa hard-coded (WorkingDirectory) è sicuramente ammissibile. In effetti la stringa è incapsulata all'interno di una proprietà e siamo matematicamente certi che sarà l'unico punto in cui stiamo esprimendo tale valore. E' altrettanto vero che questo valore non cambierà mai per tutta la durata del programma perciò questa "costante" è tale perchè è il contesto a renderla tale. Incapsulare il valore "WorkingDirectory" in Consts.WorkingDirectoryName è un plus che ci possiamo sicuramente risparmiare. Intendiamoci, male non ne fa, ma nemmeno bene.

Un'altro caso che mi è capitato di vedere, e invece considero sbagliato è l'uso di costanti per incapsulare le query SQL. Qualcosa del genere per intenderci:

   1: private const string SELECT_CATEGORIES_ORDERED_BY_ID = "SELECT * FROM Categories ORDER BY CategoryID";
   2:  
   3: ...
   4:  
   5: using (SqlCommand command = new SqlCommand(SELECT_CATEGORIES_ORDERED_BY_ID))
   6: {
   7:     // ...
   8: }

Questo uso delle costanti, per quanto a prima vista può sembrare sensato, rende il codice nettamente meno leggibile. Fatico a trovare una ragione per un codice del genere. Se l'intento è di gestire delle query che possano essere diverse perchè magari devono essere rivolte verso diversi RDBMS, non sarà l'uso delle costanti che mi risolverà il problema ma piuttosto una buona architettura ad adapter che mi consenta di scambiare il DAL agevolmente. L'unico risultato apprezzabile sarà che una volta che devo debuggare il codice sarò costretto a saltare avanti e indietro per il codice alla ricerca del valore delle costanti per cercare di capirne il significato.

In linea di massima, se il valore che state scrivendo verrà usato più di una volta è necessario incapsularlo in una costante. Se diversamente state scrivendo un valore una volta, con il sospetto che un giorno potreste usarlo altrove, ecco un altro buon motivo di metterci una costante. Ma se il valore è palese che rimarrà isolato ad una sola occorrenza, allora è già una costante, inutile ribadirlo :)

Mi raccomando, non prendete questo post come una mia personale crociata contro le costanti, è di certo meglio un codice in cui si abusi di esse piuttosto che una sola riga di codice in cui si manchi di usarne una opportunamente. Forse però, se una morale deve essere trovata, pensare a quello che si sta scrivendo è sicuramente la cosa migliore.


Aggiungi Commento