Qual è la cronologia delle denominazioni delle costanti in maiuscolo?


20

Qual è la storia dietro la convenzione delle costanti di denominazione in maiuscolo?

La mia intuizione è che è iniziato con il preprocessore C, in cui le persone hanno sviluppato una pratica per nominare le macro del preprocessore in tutte le maiuscole in modo da vivere effettivamente in uno spazio dei nomi separato ed evitare collisioni di nomi. La mia convinzione è che questa pratica sia stata poi fraintesa e bastardata da applicare anche alle costanti (pre enum, constvariabili) non preprocessore .

Nominare le macro del preprocessore in maiuscolo mi sembra davvero utile. Nominare le costanti generali in quel modo, non tanto (e controproducente se crea collisioni con nomi di macro).

Sono fuori base? La pratica di capitalizzare le costanti ha preceduto C?


3
Penso che tu sia qui. Le prime lingue avevano praticamente tutto in lettere maiuscole, con l'uso delle lettere minuscole diventava di moda in seguito. I primi libri in C sembrano mostrare in genere gli constidentificatori in minuscolo e #definesmaiuscolo. Java ha comunque adottato lettere maiuscole per le costanti e altre lingue seguite, ma potrei sbagliare un po '. Sono necessarie ulteriori ricerche! :)
David Arno,

Concordo con @DavidArno probabilmente a causa della natura del C o dell'assemblatore.
Snoop,

Risposte:


13

Per C, la prima edizione di The C Programming Language (aka K&R) suggerisce che la tua intuizione sulle macro del preprocessore è corretta:

I nomi delle costanti simboliche sono comunemente scritti in maiuscolo, quindi possono essere facilmente distinti dai nomi delle variabili in minuscolo.

In molti modi, si trattava di una sospensione dal linguaggio assembly, in cui le macro venivano definite in maiuscolo insieme a etichette, codici operativi, nomi di registro e tutto il resto. L'avvento dell'assemblaggio in stile AT & T ha cambiato quello su alcune piattaforme, ma penso che sia stato fortemente influenzato dal fatto che i terminali che supportano le lettere minuscole stavano diventando una cosa e Unix era quello che definirei un "sistema operativo minuscolo".

Sugli altri due punti, stai battendo .500:

enum

Al momento della pubblicazione della seconda edizione, enumerano stati definiti s, erano indicati come costanti di enumerazione e trattati nella sezione sulle costanti. Poiché le costanti definite da un enumsono rappresentate da simboli, ciò le rende costanti simboliche, che, se seguirai la convenzione consigliata, dovrebbero essere nominate in maiuscolo. (Come le macro del preprocessore, nulla ti impedisce di fare diversamente.)

L'implicazione qui è che, diversamente da alcuni linguaggi che seguirono, C non tratta enumcome un tipo di prima classe in cui i tipi stessi sono distinti, i valori di enumerazione sono specifici per ciascun tipo e possono essere riutilizzati in altri. Invece, è effettivamente una scorciatoia conveniente per #definequella che produce sequenze di numeri interi con identificatori collegati. Questo fa

enum foo  { BAR, BAZ };
enum quux { BLETCH, BAZ };

non valido perché tutti i simboli condividono l'ambito ed BAZè ridefinito. (Questo è stato un miglioramento rispetto al preprocessore che, al momento, non ha avvertito che uno che ne sta #definebloccando un altro.) Inoltre, a C non importa se li mescoli perché sono tutti interi, rendendo

enum foo  { BAR, BAZ };
enum quux { BLETCH, BLRFL };

enum foo variable = BLETCH;

completamente valido anche su un moderno compilatore con tutti gli avvisi attivati.

const

NB: La constparola chiave è nata nel 1981 con C With Classes di Stroustrup (che si è evoluta in C ++) e alla fine è stata adottata da C. La scelta del nome è sfortunata, perché si scontra con l'uso del termine costante di K&R per indicare ciò che ora chiameremmo un letterale (ad es. 38, 'x'o "squabble"). Il testo della seconda edizione non è stato riscritto per riflettere ciò.

Le variabili dichiarate constsono una storia diversa perché sono ancora variabili. Non dovrebbero essere modificati, ma se la nozione di una variabile costante abbia più senso di, diciamo, i gamberi giganti è foraggio per un'altra discussione. In ogni caso, C non è mai stato davvero serio al riguardo perché lo standard richiede che il compilatore emetta una diagnostica quando si tenta di cambiarne uno. Il comportamento effettivo non è definito se una modifica viene compilata ed eseguita.

Essendo variabili, ha senso che qualsiasi cosa constsegua la convenzione di essere nominato in minuscolo. Il loro utilizzo per rappresentare i valori letterali presenta alcuni vantaggi in termini di sicurezza, ma non consente una buona ottimizzazione se è necessario raggiungere le unità di compilazione per ottenere il valore.

Ciò che non sono costanti nel senso di K&R, e per questo motivo i loro identificatori non dovrebbero essere maiuscoli. Alcune persone li usano in questo modo, ma non è una pratica che raccomando tranne in alcuni casi specifici.


Accetterò questo, e mentre apprezzo la risposta, i enumparagrafi sul non essere tipi di prima classe e sui conflitti di ridefinizione non sembrano rilevanti. Che la prima edizione di K&R descriva la pratica di "costanti simboliche" è sufficiente. (Inoltre, dopo aver controllato la mia copia della seconda edizione di K&R, vedo che i loro esempi hanno tutte le enumcostanti dei nomi in maiuscolo, in modo da convalidare ulteriormente la tua risposta.)
jamesdlin
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.