Cosa c'è di sbagliato nelle corde magiche?

Come esperto sviluppatore di software, ho imparato a evitare le stringhe magiche.

Il mio problema è che è da tanto tempo che non li uso, ho dimenticato la maggior parte dei motivi. Di conseguenza, ho problemi a spiegare perché sono un problema per i miei colleghi meno esperti.

Quali ragioni oggettive ci sono per evitarle? Quali problemi causano?

1. In una lingua che viene compilata, il valore di una stringa magica non viene verificato al momento della compilazione . Se la stringa deve corrispondere a un modello particolare, è necessario eseguire il programma per garantire che si adatti a quel modello. Se hai usato qualcosa come un enum, il valore è almeno valido al momento della compilazione, anche se potrebbe essere il valore sbagliato.

2. Se una stringa magica viene scritta in più punti, è necessario cambiarli tutti senza alcuna sicurezza (come errore durante la compilazione). Questo può essere contrastato dichiarandolo in un solo posto e riutilizzando la variabile, però.

3. I refusi possono diventare gravi bug. Se hai una funzione:

   func(string foo) {
       if (foo == "bar") {
           // do something
       }
   }
   

   e qualcuno digita accidentalmente:

   func("barr");
   

   Questo è peggio, più la stringa è rara o complessa, specialmente se si hanno programmatori che non hanno familiarità con la lingua madre del progetto.

4. Le stringhe magiche raramente si documentano da sole. Se vedi una stringa, non ti dice nulla di cos'altro potrebbe / dovrebbe essere la stringa. Probabilmente dovrai esaminare l'implementazione per essere sicuro di aver scelto la stringa giusta.

   Questo tipo di implementazione presenta delle perdite , che richiedono documentazione esterna o accesso al codice per capire cosa dovrebbe essere scritto, soprattutto perché deve essere perfetto per i caratteri (come al punto 3).

5. A parte le funzioni "trova stringa" negli IDE, esiste un numero limitato di strumenti che supportano il modello.

6. Per coincidenza potresti usare la stessa corda magica in due punti, quando in realtà sono cose diverse, quindi se hai fatto un Trova e sostituisci e hai cambiato entrambi, uno di essi potrebbe rompersi mentre l'altro ha funzionato.

Il vertice di ciò che le altre risposte hanno colto non è che i "valori magici" sono cattivi, ma che dovrebbero essere:

1. definito riconoscibilmente come costanti;
2. definito una sola volta all'interno dell'intero dominio di utilizzo (se architettonicamente possibile);
3. definiti insieme se formano un insieme di costanti che sono in qualche modo correlate;
4. definito a un livello adeguato di generalità nell'applicazione in cui sono utilizzati; e
5. definito in modo tale da limitarne l'uso in contesti inappropriati (es. suscettibili di verifica del tipo).

Ciò che distingue tipicamente le "costanti" accettabili dai "valori magici" è una violazione di una o più di queste regole.

Usate bene, le costanti ci permettono semplicemente di esprimere certi assiomi del nostro codice.

Il che mi porta ad un ultimo punto, che un uso eccessivo di costanti (e quindi un numero eccessivo di ipotesi o vincoli espressi in termini di valori), anche se altrimenti rispetta i criteri di cui sopra (ma soprattutto se si discosta da essi), può implicare che la soluzione che viene elaborata non sia sufficientemente generale o ben strutturata (e quindi non stiamo più parlando dei pro e dei contro delle costanti, ma dei pro e dei contro di un codice ben strutturato).

Le lingue di alto livello hanno strutture per modelli in lingue di livello inferiore che dovrebbero impiegare costanti. Gli stessi schemi possono essere utilizzati anche nella lingua di livello superiore, ma non dovrebbero esserlo.

Ma quello può essere un giudizio di esperti basato su un'impressione di tutte le circostanze e su come dovrebbe apparire una soluzione, e esattamente come questo giudizio sarà giustificato dipenderà fortemente dal contesto. In effetti potrebbe non essere giustificabile in termini di alcun principio generale, se non per affermare che "Sono abbastanza vecchio da aver già visto questo tipo di lavoro, con cui ho familiarità, fatto meglio"!

EDIT: dopo aver accettato una modifica, rifiutata un'altra e aver ora eseguito la mia modifica, posso ora considerare lo stile di formattazione e punteggiatura del mio elenco di regole da sistemare una volta per tutte ahah!

• Sono difficili da rintracciare.
• La modifica di tutto può richiedere la modifica di più file in possibilmente più progetti (difficile da mantenere).
• A volte è difficile dire quale sia il loro scopo semplicemente osservando il loro valore.
• Nessun riutilizzo.

Esempio di vita reale: sto lavorando con un sistema di terze parti in cui "entità" sono memorizzate con "campi". Fondamentalmente un sistema EAV . Poiché è abbastanza facile aggiungere un altro campo, puoi accedervi utilizzando il nome del campo come stringa:

Field nameField = myEntity.GetField("ProductName");

(nota la stringa magica "ProductName")

Ciò può comportare diversi problemi:

• Devo fare riferimento alla documentazione esterna per sapere che esiste anche "ProductName" e la sua ortografia esatta
• Inoltre, devo fare riferimento a quel documento per vedere qual è il tipo di dati di quel campo.
• I Typos in questa stringa magica non verranno catturati fino a quando questa riga di codice non verrà eseguita.
• Quando qualcuno decide di rinominare questo campo sul server (difficile mentre si impedisce la perdita dei dati, ma non impossibile), non riesco facilmente a cercare nel mio codice per vedere dove dovrei modificare questo nome.

Quindi la mia soluzione era quella di generare costanti per questi nomi, organizzate per tipo di entità. Quindi ora posso usare:

Field nameField = myEntity.GetField(Model.Product.ProductName);

È ancora una costante di stringa e si compila esattamente nello stesso binario, ma presenta diversi vantaggi:

• Dopo aver digitato "Modello", il mio IDE mostra solo i tipi di entità disponibili, quindi posso selezionare facilmente "Prodotto".
• Quindi il mio IDE fornisce solo i nomi dei campi disponibili per questo tipo di entità, anch'essi selezionabili.
• La documentazione generata automaticamente mostra qual è il significato di questo campo più il tipo di dati utilizzato per archiviare i suoi valori.
• A partire dalla costante, il mio IDE può trovare tutti i luoghi in cui viene utilizzata quella costante esatta (al contrario del suo valore)
• Typos verrà catturato dal compilatore. Questo vale anche quando si utilizza un modello nuovo (possibilmente dopo aver rinominato o eliminato un campo) per rigenerare le costanti.

Avanti sul mio elenco: nascondi queste costanti dietro a classi fortemente tipizzate generate - quindi anche il tipo di dati è protetto.

Le stringhe magiche non sono sempre cattive , quindi questo potrebbe essere il motivo per cui non puoi trovare un motivo generale per evitarle. (Per "stringa magica" suppongo che intendi letterale stringa come parte di un'espressione e non definita come costante.)

In alcuni casi particolari, le stringhe magiche dovrebbero essere evitate:

• La stessa stringa appare più volte nel codice. Ciò significa che potresti avere un errore di ortografia in uno dei luoghi. E sarà una seccatura delle modifiche alla stringa. Trasforma la stringa in una costante e eviterai questo problema.
• La stringa può cambiare indipendentemente dal codice in cui appare. Per esempio. se la stringa è un testo visualizzato all'utente finale, probabilmente cambierà indipendentemente da qualsiasi cambiamento logico. Separare tale stringa in un modulo separato (o configurazione esterna o database) renderà più semplice il cambio indipendente
• Il significato della stringa non è evidente dal contesto. In tal caso, l'introduzione di una costante renderà il codice più semplice da comprendere.

Ma in alcuni casi, le "corde magiche" vanno bene. Supponi di avere un semplice parser:

switch (token.Text) {
  case "+":
    return a + b;
  case "-":
    return a - b;
  //etc.
}

Non c'è davvero nessuna magia qui, e nessuno dei problemi sopra descritti si applica. Non ci sarebbe alcun beneficio da definire da parte di IMHO, string Plus="+"ecc. Semplificare.

Per aggiungere alle risposte esistenti:

Internazionalizzazione (i18n)

Se il testo da visualizzare sullo schermo è codificato e sepolto all'interno di livelli di funzioni, avrai difficoltà a fornire traduzioni di quel testo in altre lingue.

Alcuni ambienti di sviluppo (ad es. Qt) gestiscono le traduzioni mediante la ricerca da una stringa di testo nella lingua di base nella lingua tradotta. Le stringhe magiche possono generalmente sopravvivere a questo - fino a quando non decidi di voler usare lo stesso testo altrove e ottenere un refuso. Anche allora, è molto difficile trovare quali stringhe magiche devono essere tradotte quando si desidera aggiungere il supporto per un'altra lingua.

Alcuni ambienti di sviluppo (ad esempio MS Visual Studio) adottano un altro approccio e richiedono che tutte le stringhe tradotte siano conservate in un database di risorse e rilette per la locale corrente dall'ID univoco di quella stringa. In questo caso, l'applicazione con stringhe magiche semplicemente non può essere tradotta in un'altra lingua senza importanti rilavorazioni. Lo sviluppo efficiente richiede che tutte le stringhe di testo siano inserite nel database delle risorse e che ricevano un ID univoco quando il codice viene scritto per la prima volta, e in seguito i18n è relativamente semplice. Cercare di riempire questo dopo il fatto in genere richiederà uno sforzo molto grande (e sì, ci sono stato!), Quindi è molto meglio fare le cose in primo luogo.

Questa non è una priorità per tutti, ma se mai vuoi essere in grado di calcolare le metriche di accoppiamento / coesione sul tuo codice in modo automatizzato, le stringhe magiche lo rendono quasi impossibile. Una stringa in un posto farà riferimento a una classe, un metodo o una funzione in un altro posto e non esiste un modo semplice e automatico per determinare che la stringa è accoppiata alla classe / metodo / funzione semplicemente analizzando il codice. Solo la struttura sottostante (angolare, ad es.) Può determinare l'esistenza di un collegamento e può farlo solo in fase di esecuzione. Per ottenere le informazioni di accoppiamento da soli, il tuo parser dovrebbe sapere tutto sul framework che stavi utilizzando, oltre e oltre la lingua di base in cui stai codificando.

Ma ancora una volta, questo non è qualcosa che interessa molto agli sviluppatori.