Le costanti a carattere singolo sono migliori delle letterali?

Tautologia :

It is very clear if you read the very first sentence of the question that this question is not about appropriate uses like eliminating magic numbers, it is about terrible mindless foolish consistency at best. Which is what this answer addresses

Il buon senso ti dice che const char UPPER_CASE_A = 'A'; o const char A = 'A' non aggiunge nulla ma manutenzione e complessità al tuo sistema. const char STATUS_CODE.ARRIVED = 'A' è un caso diverso.

Le costanti si suppone rappresentino elementi immutabili in fase di esecuzione, ma potrebbero dover essere modificati in futuro in fase di compilazione. Quando const char A = equivarrà correttamente a qualsiasi valore diverso da A ?

Se vedi public static final char COLON = ':' nel codice Java, trova chi ha scritto quello e interrompe le loro tastiere. Se la rappresentazione di COLON cambia mai da : avremo un incubo di manutenzione.

Offuscamento:

Che cosa accade quando qualcuno lo modifica in COLON = '-' , perché dove lo stanno utilizzando ha bisogno invece di - ovunque? Stai per scrivere dei test unitari che in pratica dicono assertThat(':' == COLON) per ogni singolo riferimento const per assicurarti che non vengano modificati? Solo per avere qualcuno risolvere il test quando li cambia?

Se qualcuno sostiene che public static final String EMPTY_STRING = ""; è utile e vantaggioso, hai appena qualificato le loro conoscenze e ignorato in sicurezza su tutto il resto.

Avere tutti i caratteri stampabili disponibili con una versione denominata dimostra semplicemente che chiunque l'abbia fatto, non è qualificato per scrivere codice senza supervisione.

coesione:

Inoltre riduce artificialmente la coesione, perché allontana le cose dalle cose che le usano e sono correlate a loro.

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highly cohesive systems functionality is strongly related.

Coupling:

Accoppia anche molte classi non correlate perché finiscono per fare riferimento a file che non sono realmente correlati a ciò che fanno.

Tight coupling is when a group of classes are highly dependent on one another. This scenario arises when a class assumes too many responsibilities, or when one concern is spread over many classes rather than having its own class.

Se hai usato un nome migliore come DELIMITER = ',' avresti ancora lo stesso problema, perché il nome è generico e non ha semantica. La riassegnazione del valore non serve più per eseguire un'analisi dell'impatto rispetto alla ricerca e alla sostituzione per il valore letterale ',' . Perché quello che è un codice lo usa e ha bisogno del , e qualche altro codice usa ma ha bisogno di ; ora? Devo comunque esaminare ogni utilizzo manualmente e cambiarli.

In the Wild:

Recentemente ho refactored un'applicazione 1,000,000+ LOC che aveva 18 anni. Aveva cose come public static final COMMA = SPACE + "," + SPACE; . Questo non è in alcun modo migliore della semplice integrazione di " , " dove è necessario.

Se vuoi discutere di leggibilità devi imparare a configurare l'IDE per visualizzare whitespace caratteri dove puoi vederli o qualsiasi altra cosa, questo è solo un motivo estremamente pigro per introdurre l'entropia in un sistema.

Aveva anche , definito più volte con più errori di ortografia della parola COMMA in più pacchetti e classi. Con riferimenti a tutte le variazioni mescolate insieme nel codice. E 'stato a dir poco un incubo provare a riparare qualcosa senza rompere qualcosa di completamente non correlato.

Come per l'alfabeto, c'erano più UPPER_CASE_A , A , UPPER_A , A_UPPER che la maggior parte delle volte erano pari a A ma in alcuni casi non erano . Per quasi tutti i personaggi, ma non tutti i personaggi.

E dalle cronologie dell'editing non sembrava che uno solo di questi fosse mai stato modificato o modificato nel corso dei 18 anni, a causa di quello che dovrebbe essere ovvio, la ragione è che spezzerebbe troppe cose che non erano rintracciabili, quindi tu avere nuovi nomi di variabili che puntano alla stessa cosa che non può mai essere cambiata per lo stesso motivo.

In nessuna realtà sensata puoi affermare che questa pratica non sta facendo altro che partire alla massima entropia.

Ho rifattorizzato tutto questo casino e ho delineato tutte le tautologie e le nuove assunzioni al college sono state molto più produttive perché non dovevano dare la caccia a più livelli di riferimento indiretto su cosa questi riferimenti di const puntassero effettivamente, perché non erano affidabile in ciò che sono stati nominati rispetto a ciò che contenevano.

The main appeal of using constants is they minimize maintenance when a change is needed.

ASSOLUTAMENTE NO. Questo è per nulla il motivo per usare le costanti perché le costanti non cambiano per definizione . Se una costante cambia mai allora non era una costante, vero?

L'attrattiva dell'uso delle costanti non ha assolutamente nulla a che fare con la gestione dei cambiamenti e tutto ciò che ha a che fare con rendendo i programmi suscettibili di essere scritti, compresi e mantenuti dalle persone . Se voglio sapere dovunque nel mio programma in cui un colon è usato come separatore di URL, allora posso sapere molto facilmente se ho la disciplina per definire un URLSeparator costante, e non posso saperlo facilmente se devo fare il grep per : e ottieni ogni singolo posto nel codice dove : è usato per indicare una classe base, o un operatore ?: , o qualsiasi altra cosa.

Sono completamente in disaccordo con le altre risposte che affermano che si tratta di una perdita inutile di tempo. Le costanti nominate aggiungono che significa a un programma e tali semantiche possono essere utilizzate sia dagli umani sia dalle macchine per comprendere un programma in modo più approfondito e mantenerlo in modo più efficace.

Il trucco qui non è quello di evitare le costanti, ma piuttosto di nominarle con le loro proprietà semantiche piuttosto che le loro proprietà sintattiche . A cosa serve la costante? Non chiamarlo Comma a meno che il dominio aziendale del tuo programma sia tipografia, analisi della lingua inglese o simili. Chiamalo ListSeparator o qualcosa del genere, per rendere chiara la semantica della cosa.

No, è stupido.

Ciò che è non necessariamente stupido sta tirando cose del genere in etichette con nome per ragioni di localizzazione. Ad esempio, il delimitatore di migliaia è una virgola in America (1.000.000), ma non una virgola in altre locali. Tirando questo in un'etichetta con nome (con un nome appropriato, non-virgola) consente al programmatore di ignorare / astrarre quei dettagli.

Ma fare una costante perché "le stringhe magiche sono cattive" è solo setta del carico.

Ci sono alcuni caratteri che possono essere ambigui o utilizzati per diversi scopi. Ad esempio, utilizziamo '-' come un trattino, un segno meno o addirittura un trattino. Puoi creare nomi separati come:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '-';
static const wchar_t EM_DASH = '-';

In seguito, potresti scegliere di modificare il codice per disambigarlo ridefinendoli come:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '\u2122';
static const wchar_t EM_DASH = '\u2014';

Questa potrebbe essere una ragione per cui consideri la definizione di costanti per determinati singoli caratteri. Tuttavia , il numero di caratteri che sono ambigui in questo modo è piccolo. Al massimo, sembra che lo faresti solo per quelli. Direi anche che potresti aspettare fino a quando non avrai effettivamente bisogno di distinguere i caratteri ambigui prima di calcolare il codice in questo modo.

Poiché le convenzioni tipografiche possono variare in base alla lingua e alla regione, probabilmente è meglio caricare questa punteggiatura ambigua da una tabella di traduzione.

Una costante deve aggiungere significato.

La definizione di COMMA come una virgola non aggiunge significato, poiché sappiamo che una virgola è una virgola. Al contrario, distruggiamo il significato, perché ora la COMMA potrebbe non essere più una virgola.

Se si utilizza una virgola per uno scopo e si desidera utilizzare una costante denominata, denominarla dopo il suo scopo. Esempio:

• city + CharacterClass.COMMA + state = cattivo
• city + CITY_STATE_DELIMITER + state = buono

Utilizza le funzioni per la formattazione

Personalmente preferisco FormatCityState(city, state) e non mi interessa come appare il corpo di quella funzione finché è breve e passa i test case.

L'idea che una costante COMMA sia migliore di ',' o "," è piuttosto facile da ridimensionare. Certo, ci sono casi in cui ha senso, per esempio fare final String QUOTE = "\""; fa risparmiare pesantemente sulla leggibilità senza tutte le barre, ma escludendo caratteri di controllo della lingua come \ ' e " Non li ho trovati molto utile.

L'utilizzo di final String COMMA = "," non è solo una cattiva forma, è pericoloso! Quando qualcuno vuole cambiare il separatore da "," a ";" potrebbe andare a cambiare il file delle costanti in COMMA = ";" perché è più veloce per loro farlo e funziona. Tranne, lo sai, tutte le altre cose che hanno utilizzato COMMA ora sono anche punti e virgola, incluse le cose inviate a consumatori esterni. Quindi passa tutti i test (perché tutto il codice di marshalling e unmarshalling utilizzava anche COMMA) ma i test esterni falliscono.

Ciò che è utile è dare loro nomi utili. E sì, a volte più costanti avranno lo stesso contenuto ma nomi diversi. Ad esempio final String LIST_SEPARATOR = "," .

Quindi la tua domanda è "sono costanti di char singole migliori di quelle letterali" e la risposta è inequivocabilmente no, non lo sono. Ma anche meglio di entrambi è un nome di variabile strettamente definito che dice esplicitamente qual è il suo scopo. Certo, passerai qualche byte in più su quei riferimenti extra (supponendo che non vengano compilati su di te, cosa che probabilmente lo faranno) ma nella manutenzione a lungo termine, che è dove è la maggior parte del costo di un'applicazione, essi valgono il tempo di fare.

Ho fatto un po 'di lavoro a scrivere lexer e parser e ho usato le costanti integer per rappresentare i terminali. I terminali a carattere singolo avevano il codice ASCII come valore numerico per semplicità, ma il codice avrebbe potuto essere qualcos'altro. Quindi, avrei un T_COMMA a cui è stato assegnato il codice ASCII per "," come valore costante. Tuttavia, c'erano anche costanti per nonminerminali a cui erano stati assegnati interi al di sopra del set ASCII. Osservando i generatori di parser come yacc o bison, o parser scritti usando questi strumenti, ho avuto l'impressione che sia fondamentalmente come tutti hanno fatto.

Quindi, mentre, come tutti gli altri, penso che sia inutile definire costanti con lo scopo esplicito di utilizzare le costanti anziché i letterali in tutto il codice, penso che ci siano casi limite (parser, diciamo) in cui potresti incontrare codice crivellato da costanti come quelle che descrivi. Si noti che nel caso del parser, le costanti non sono solo lì per rappresentare i caratteri letterali; rappresentano entità che potrebbero semplicemente accadere essere letterali di caratteri.

Posso pensare ad alcuni casi isolati in cui potrebbe avere senso usare le costanti invece dei letterali corrispondenti. Ad esempio, potresti definire NEWLINE come letterale '\ n' su una finestra unix, ma '\ r \ n' o '\ n \ r' se sei su windows o mac box. Lo stesso vale per l'analisi di file che rappresentano dati tabulari; puoi definire costanti FIELDSEPARATOR e RECORDSEPARATOR. In questi casi, stai definendo una costante per rappresentare un personaggio che serve una determinata funzione. Comunque, se tu fossi un programmatore alle prime armi, forse dovresti nominare il tuo separatore di campo costante COMMA, non rendendoti conto che avresti dovuto chiamarlo FIELDSEPARATOR, e quando hai capito, il codice sarebbe stato in produzione e tu saresti sul prossimo progetto, quindi la costante chiamata in modo errato rimarrà nel codice per qualcuno che in seguito troverà e scuoterà la testa.

Infine, la pratica che descrivi potrebbe avere senso in alcuni casi in cui scrivi codice per gestire i dati codificati in una codifica di caratteri specifica, ad esempio iso-8859-1, ma aspettati che la codifica cambi più tardi. Ovviamente in questo caso sarebbe molto più logico usare le librerie di localizzazione o codifica e decodifica per gestirle, ma se per qualche motivo non si potesse usare una tale libreria per gestire i problemi di codifica per te, usando le costanti che avresti solo ridefinire in un singolo file invece di letterali codificati disseminati su tutto il codice sorgente potrebbe essere un modo per andare.

Per quanto riguarda l'articolo a cui ti sei collegato: non penso che cerchi di creare un caso per sostituire i caratteri letterali con le costanti. Penso che stia cercando di illustrare un metodo per usare le interfacce per tirare le costanti in altre parti della tua base di codice. Le costanti di esempio utilizzate per illustrare questo sono scelte molto male, ma non penso che abbiano importanza in alcun modo.

Oltre a tutte le belle risposte qui, vorrei aggiungere uno spunto di riflessione, che una buona programmazione riguarda la fornitura di astrazioni appropriate che possono essere costruite su da soli e forse dagli altri, senza dover ripetere lo stesso codice più e più volte.

Buone astrazioni rendono il codice facile da usare da un lato e facile da mantenere dall'altro.

Sono totalmente d'accordo sul fatto che DELIMITER=':' sia di per sé un'astrazione povera, e solo migliore di COLON=':' (dato che quest'ultimo è totalmente impoverito).

Una buona astrazione che coinvolge stringhe e separatori include un modo per impacchettare uno o più singoli elementi di contenuto nella stringa e per decomprimerli anche dalla stringa impacchettata, prima di tutto, prima di dirti quale sia il delimitatore. Tale astrazione verrebbe impacchettata come un concetto, nella maggior parte delle lingue come una classe; ad esempio, in modo che il suo utilizzo sia praticamente auto-documentante, in quanto è possibile cercare tutti i luoghi in cui viene utilizzata questa classe ed essere sicuri dell'intenzione del programmatore riguardo al formato delle stringhe compresse in ciascun caso in cui viene utilizzata un'astrazione.

Una volta fornita una tale astrazione, sarebbe facile da usare senza mai dover consultare quale sia il valore di DELIMITER o COLON e, cambiando i dettagli di implementazione, generalmente si limiterà all'implementazione. Quindi, in breve, queste costanti dovrebbero davvero essere i dettagli di implementazione nascosti all'interno di un'appropriata astrazione.

The main appeal of using constants is they minimize maintenance when a change is needed.

Le buone astrazioni, che sono in genere composizioni di diverse funzionalità correlate, sono migliori nel minimizzare la manutenzione. Innanzitutto, separano chiaramente il fornitore dai consumatori. Secondo, nascondono i dettagli di implementazione e forniscono invece funzionalità direttamente utili. In terzo luogo, documentano a un livello elevato quando e dove vengono utilizzati.

L'unica volta in cui ho visto tali costanti utilizzate in modo efficace è la corrispondenza con un'API o un documento esistente. Ho visto simboli come COMMA usati perché un particolare software è stato collegato direttamente a un parser che utilizzava COMMA come tag in un albero di sintassi astratto. Ho anche visto che era usato per abbinare una specifica formale. nelle specifiche formali, a volte vedi simboli come COMMA anziché ',' perché vogliono essere il più completamente chiari possibile.

In entrambi i casi, l'uso di un simbolo denominato come COMMA contribuisce a fornire coesione a un prodotto altrimenti disgiunto. Questo valore può spesso superare il costo delle notazioni eccessivamente prolisse.

Osserva che stai provando a creare una lista.

Quindi, refactor come String makeList(String[] items)

In altre parole, elimina la logica anziché i dati .
Le lingue potrebbero essere diverse nel modo in cui rappresentano le liste, ma le virgole sono sempre virgole (è una tautologia). Quindi, se la lingua cambia, la modifica del carattere virgola non ti aiuterà, ma lo farà.

Se questa era una classe scritta come parte di un'applicazione dal tuo collega sviluppatore, questa è quasi certamente una cattiva idea. Come già sottolineato da altri, ha senso definire costanti come SEPARATOR = ',' in cui è possibile modificare il valore e la costante ha ancora senso, ma molto meno costanti il cui nome descrive solo il loro valore.

Tuttavia, ci sono almeno due casi in cui ha senso dichiarare costanti il cui nome descrive esattamente il loro contenuto e in cui non è possibile modificare il valore senza modificare in modo appropriato il nome della costante:

• Costanti matematiche o fisiche, ad es. %codice%. Qui, il ruolo della costante è quello di agire come un mnemonico poiché il nome simbolico PI = 3.14159 è molto più breve e più leggibile del valore che rappresenta.
• Elenco esaustivo di simboli in un parser o tasti su una tastiera. Potrebbe anche avere senso avere un elenco di costanti con la maggior parte o tutti i caratteri Unicode e questo è il caso in cui il tuo caso potrebbe cadere. Alcuni personaggi come PI sono ovvi e chiaramente riconoscibili. Ma puoi facilmente distinguere A e А a parte? Il primo è lettera cirillica À mentre il secondo è lettera latina A . Sono lettere diverse, rappresentate da diversi punti di codice Unicode, anche se graficamente sono quasi identici. Preferisco avere costanti A e CYRILLIC_CAPITAL_A nel mio codice rispetto a due caratteri dall'aspetto quasi identico. Naturalmente, questo è inutile se sai che lavorerai solo con caratteri ASCII che non contengono Cirillico. Allo stesso modo: uso l'alfabeto latino giorno per giorno, quindi se dovessi scrivere un programma che necessitasse di un carattere cinese, probabilmente preferirei usare una costante piuttosto che inserire un carattere che non capisco. Per qualcuno che usa i caratteri cinesi giorno per giorno, un personaggio cinese può essere ovvio, ma uno latino può essere più facile da rappresentare come costante nominata. Quindi, come vedi, dipende dal contesto. Tuttavia, una libreria potrebbe contenere costanti simboliche per tutti i caratteri poiché gli autori non possono sapere in anticipo come verrà utilizzata la libreria e quali caratteri potrebbero aver bisogno di costanti per migliorare la leggibilità in un'applicazione specifica.

Tuttavia, tali casi sono generalmente gestiti da classi di sistema o librerie a scopo speciale e la loro presenza nel codice scritto dagli sviluppatori di applicazioni dovrebbe essere molto rara, a meno che non si stia lavorando su un progetto molto speciale.

Forse.

Le costanti a carattere singolo sono relativamente difficili da distinguere. Quindi può essere piuttosto facile perdere il fatto che stai aggiungendo un punto anziché una virgola

city + '.' + state

mentre è un errore relativamente difficile da fare con

city + Const.PERIOD + state

A seconda del tuo ambiente di internazionalizzazione e globalizzazione, la differenza tra un apostrofo ASCII e l'apostrofo aperto e chiuso di Windows-1252 (o il doppio apice ASCII e il doppio apice di Windows 1252 apri e chiudi) può essere significativo ed è notoriamente difficile per visualizzare il codice.

Ora, presumibilmente, se per sbaglio fosse un periodo piuttosto che una virgola era un problema funzionale significativo, avresti un test automatico che avrebbe trovato l'errore di battitura. Se il tuo software sta generando file CSV, mi aspetterei che la tua suite di test scoprisse abbastanza rapidamente che hai avuto un periodo tra la città e lo stato. Se il software dovrebbe funzionare per i client con una varietà di configurazioni di internazionalizzazione, presumibilmente la suite di test verrà eseguita in ogni ambiente e verrà rilevata se si dispone di un preventivo aperto di Microsoft se si intende avere un apostrofo.

Potevo immaginare un progetto in cui aveva più senso optare per un codice più dettagliato che potesse risolvere questi problemi in particolare quando si ha codice vecchio che non ha una suite di test completa anche se probabilmente non codificherei in questo modo in un progetto di sviluppo del campo verde. E aggiungere una costante per ogni carattere di punteggiatura piuttosto che solo quelli che sono potenzialmente problematici nella tua particolare applicazione è probabilmente eccessivo.

Are single-character constants better than literals?

Ci sono un sacco di conflazioni che galleggiano qui intorno. Fammi vedere se riesco a metterli a parte.

Le costanti forniscono:

• semantica
• cambia, durante lo sviluppo
• indirezione

Il ridimensionamento del nome di un singolo carattere influisce solo sulla semantica. Un nome dovrebbe essere utile come commento e chiaro nel contesto. Dovrebbe esprimere il significato, non il valore. Se può fare tutto ciò con una singola multa di carattere. Se non può, per favore non farlo.

Un letterale e una costante possono entrambi cambiare durante lo sviluppo. Questo è ciò che fa sorgere il problema del numero magico. Le stringhe possono essere anche numeri magici.

Se il significato semantico esiste, e dal momento che entrambi sono costanti, allora se la costante ha più valore di un letterale si riduce a indirezione.

L'indirection può risolvere qualsiasi problema, a parte una grande indecisione.

L'indirection può risolvere il problema del numero magico perché consente di decidere un valore per un'idea in un unico punto. Semanticamente, perché ciò valga la pena, il nome deve rendere chiara l'idea. Il nome dovrebbe riguardare l'idea, non il valore.

L'indirazione può essere esagerata. Alcuni preferiscono cercare e sostituire i letterali per apportare le loro modifiche. Va bene fino a quando 42 è chiaramente il significato della vita e non è mescolato con 42, il numero atomico di molibdeno.

Dove puoi fare distinzioni utili come quella con una singola lettera dipende in gran parte dal contesto. Ma non vorrei prendere l'abitudine.

Come contrappunto filosofico all'opinione di maggioranza, devo affermare che ci sono alcuni di noi, che apprezzano il programmatore contadino francese del XIX secolo e non sofisticato e

remembered his monotonous, everlasting lucidity, his stupefyingly sensible views of everything, his colossal contentment with truisms merely because they were true. "Confound it all!" cried Turnbull to himself, "if he is in the asylum, there can't be anyone outside."

G.K. Chesterton, The Ball and The Cross

Non c'è nulla di sbagliato nell'apprezzare la verità e non c'è nulla di sbagliato nell'affermare la verità, specialmente quando si parla con un computer.

If you lie to the computer, it will get you

Perry Farrar - Germantown, Maryland (from More Programming Pearls )

Ma, per la maggior parte, sono d'accordo con le persone che dicono che è stupido. Sono troppo giovane per aver imparato a programmare FORTRAN, ma ho sentito dire che potresti ridefinire 'A' = 'Q' e inventare tutti i tipi di meravigliosi crittogrammi. Non lo stai facendo.

Oltre i problemi i18n presentati in precedenza (che non stanno ridefinendo il glifo "COMMA", ma ridefinendo veramente il glifo di un DECIMAL_POINT). Costruire citazioni di carote francesi o virgolette inglesi singole per trasmettere significato agli umani è una cosa e quelle dovrebbero essere davvero variabili, non costanti. La costante sarebbe AMERICAN_COMMA := ',' e comma := AMERICAN_COMMA

E, se usassi un modello di builder per costruire una query SQL, preferirei vedere

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(" ( ")
 .append(val_1)
 .append(",")
 .append(val_2)
 .append(" ); ")

di qualsiasi altra cosa, ma se avessi intenzione di aggiungere costanti, sarebbe

INSERT_VALUES_START = " ( "
INSERT_VALUES_END = " ) "
INSERT_VALUES_SEPARATOR = " , "
QUERY_TERMINATOR = ";"

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(INSERT_VALUES_START)
 .append(val_1)
 .append(INSERT_VALUES_SEPARATOR)
 .append(val_2)
 .append(INSERT_VALUES_END)
 .append(QUERY_TERMINATOR)

Tuttavia, se hai mai visto qualcun altro programma (o tipo) potresti notare alcune stranezze interessanti. Non tutti noi siamo dattilografi stellari. Molti di noi sono arrivati a programmare in ritardo o sono stati generati con tastiere sovietiche (dove i tasti digitano su di te) e ci piace tagliare e incollare singole lettere invece di provare a trovarli sulla tastiera e / o fare affidamento su completamento automatico.

Niente completerà automaticamente una stringa per te, quindi se riesco a ottenere una virgola premendo 'con', alt-space, down, down, down, inserisci e ottieni una citazione premendo 'con', alt-space , giù, giù, entra. Potrei farlo.

Un'altra cosa da ricordare sui letterali stringa è il modo in cui sono compilati. Almeno in Delphi, (che è l'unico linguaggio che ho ossessionato con la pila di), finirai per inserire i tuoi letterali nella pila di ogni funzione. Quindi, molti valori letterali = un sacco di funzioni generali; "," in function_A non è lo stesso bit di memoria di un "," in function_B ". Per combatterlo, c'è una" resource string "che può essere costruita e collegata in sideways - ed è così che fanno i18n stuff (uccisione due uccelli con un cespuglio). In Python tutti i valori letterali delle stringhe sono oggetti, e in effetti potrebbe sembrare bello usare utils.constants.COMMA.join(["some","happy","array","strings"]) , ma non è un'idea stellare per i punti ripetuti più e più volte su questa pagina.

But when are we going to start using a different symbol than ',' to represent a comma?

Per la localizzazione.

Nei paesi di lingua inglese, il simbolo che separa l'intero e le parti frazionarie di un decimale è ".", che chiamiamo "punto decimale". In molti altri paesi, il simbolo è "," ed è in genere chiamato l'equivalente di "virgola" nella lingua locale. Allo stesso modo, dove i paesi di lingua inglese usano "," per separare gruppi di tre cifre in grandi numeri (come 1.000.000 per un milione), i paesi che usano una virgola come punto decimale usano un punto (1.000.000).

Quindi c'è un caso per fare costanti DECIMAL_POINT e COMMA se si sta facendo globalizzazione.