Naming: Perché le costanti nominate dovrebbero essere tutte maiuscole in C++/Java?

Question

Lo so, che per C++ e Java è una convenzione di denominazione consolidata, che le costanti devono essere scritte tutte in maiuscolo, con caratteri di sottolineatura per separare le parole. Ti piace questa (Java-esempio):

public final static Color BACKGROUND_COLOR = Color.WHITE; 
public final static Color TEXT_COLOR = Color.BLACK; 

Questa convenzione di denominazione è facile da capire e da seguire, ma mi chiedo, perché scegliere questa convenzione di denominazione sopra il normale denominazione-convenzione per variabili:

public final static Color backgroundColor = COLOR.WHITE; 
public final static Color textColor = COLOR.BLACK; 

Theres sembra non aver bisogno di cambiare l'aspetto delle costanti. Se vogliamo assegnare loro un valore, il compilatore lo impedirà comunque. In realtà crea problemi, se in seguito la costante verrà modificata in una variabile corretta (perché i colori diventano configurabili ad esempio).

Quindi qual è il motivo ultimo per scrivere costanti denominate tutte maiuscole? Ragioni storiche?

Answer 1

Probabilmente hai ragione. I computer e i compilatori (soprattutto) non erano così veloci come oggi.

Joel Spolsky menzionato in one of his essays quanto è rimasto impressionato dai tempi di compilazione della nuova versione di Turbo Pascal.

Mi ricordo quando la compilazione di non troppo grande programma (10-20KLOC) con sovrapposizioni in Turbo Pascal 5.0 su PC XT 10MHz voluti circa 20 minuti ...

Suppongo che l'attesa per la compilazione per rilevare l'errore non è stato accettabile.

E una convenzione del genere aiuta a evitare errori e perdite di tempo durante la compilazione interrotta.

Answer 2

Posso immaginare che inizialmente, nei giorni C, la gente avrebbe attuare "costanti" simbolicamente, con il pre-processore:

typedef unsigned int Color; 
#define BACKGROUND_COLOR 0xffffff 

Tali "costanti" sono letterali solo prettified, e come tali non comportarti come variabili. Non si può, ad esempio, prendere l'indirizzo di un tale "costante":

Color *p = &BACKGROUND_COLOR; // Breaks! 

Per questo motivo, ha senso per averli "spiccano", in quanto sono in realtà non solo "variabili non può cambiare ".

Answer 3

Con le costanti maiuscole le formule lunghe sono molto più facili da leggere, non è necessario indovinare quale elemento può variare e quali no. Ovviamente è solo una convenzione, ma utile.

Answer 4

Penso che non sia un problema tecnico ma piuttosto psicologico. Le convenzioni di denominazione non sono elaborate dal compilatore (il computer non si preoccupa dei nomi), ma piuttosto dal programmatore che sta sfogliando il codice per avere quante più informazioni possibili con il minimo sforzo richiesto.

L'utilizzo di una convenzione di denominazione diversa indica chiaramente al lettore che ciò che state leggendo è qualcosa che è FISSATO in fase di compilazione e non è necessario seguire il codice per determinare dove e come il valore è arrivato.

Answer 5

Se so che qualcosa è una costante, posso farvi riferimento più volte e sapere che non cambierà.In altre parole, lo so che:

Color black = Colors.BLACK; 
foo(black); 
foo(black); 

è lo stesso:

foo(Colors.BLACK); 
foo(Colors.BLACK); 

che può essere utile sapere a volte. Personalmente preferisco la convenzione di denominazione NET, che è quello di utilizzare caso Pascal per le costanti (e metodi):

Foo(Colors.Black); 
Foo(Colors.Black); 

Io non sono un grande fan di caso shouty ... ma mi piace essere costanti, ovviamente, costanti .

Answer 6

E 'una soluzione per i tuoi strumenti di sviluppo non essere in grado di individuare le proprietà di un identificatore in un modo conveniente.

Molto simile alla notazione ungherese.

Quando il vostro IDE viene meglio, non sarà necessario alcun convenzione di denominazione, ma quella che impone che un nome è informazioni complete su ciò che significa un identificatore.

Anche questo può evolvere: perché non creare un sistema di programmazione in cui basta creare identificatori, e aggiungere proprietà ad esso come "breve descrizione", "tipo", ... Quando lo strumento arriva che può fare questo in un comodo modo, sono dentro. "Intentional Programming" è un suggerimento.

Answer 7

In fase di programmazione, è importante creare un codice che sia comprensibile dagli esseri umani. Avere convenzioni di denominazione aiuta a farlo. Questo è il migliore quando si guarda il codice che non si è scritto e rende il codice più gestibile in quanto è facile distinguere da costanti e variabili.

Answer 8

Credo in C++ è una convenzione riportati dai giorni di utilizzo del preprocessore #define valori costanti. Allora, è stato fatto per evitare che il preprocessore calpestasse tutto il codice sorgente, in quanto le solite convenzioni per la funzione C e i nomi variabili li renderebbero maiuscole o minuscole.

Da un punto di vista C++, direi che si tratta di una cattiva idea per rendere i vostri costanti tutto maiuscolo. Ho dovuto eseguire il debug di più di un problema di build a causa di ciò - ricorda che il preprocessore C++ non sa nulla di spazi dei nomi e scope di denominazione e sostituirà felicemente ciò che ritiene sia appropriato anche se è piuttosto inappropriato.

Answer 9

Le conversioni di codifica devono migliorare la leggibilità. Non devi usare lettere. Java consente, ad esempio, il simbolo $.

public final static Color $$ = COLOR.WHITE; 
public final static Color $_ = COLOR.BLACK; 

È possibile numerare anche le variabili, ma ciò non significa che sia una buona idea. ;)

Answer 10

Penso costanti maiuscoli sono una cattiva eredità da C. La logica è dietro la stessa di quando si utilizza underscore come prefissi per i membri privati. Questo è materiale tecnico che è già espresso da parole chiave Java come private o, nel caso di costanti, static final.

Consulta anche: http://weblogs.java.net/blog/2006/09/28/case-against-uppercases

Answer 11

In C (e quindi C++), i simboli che sono stati definiti con la direttiva del preprocessore #define sono stati scritti tutti in maiuscolo come un segnale forte per gli sviluppatori che il codice non era come sembrava e non trattare come un simbolo normale. Le costanti inizialmente non esistevano in K & R C (anche se const è stato ripristinato da C++ in seguito) quindi gli sviluppatori utilizzavano invece #define, quindi i cappucci.

Per qualche motivo, questo è stato convertito in Java come "le costanti sono tappi", da qui l'attuale convenzione errata (IMO).

Answer 12

È sicuramente un problema tecnico in Java. Si consideri:

import static com.test.constants.white; 
public class Foo { 
    void bar(){ 
    //String white = "black"; 
    String whatAmI = white; 
    } 
} 

Qual è il valore di "WHATAMI" prima e dopo togliendo il commento alla riga precedente?

Se il nome della costante ha la stessa convenzione del nome della variabile locale, ciò causerà problemi di codice REALE. Le costanti dovrebbero sempre avere la convenzione UPPERCASE per evitare questo.

Answer 13

Fondamentalmente, quando le persone erano innamorate di C e C++ & Java erano nuove o non ancora create, le persone usavano tutte le maiuscole per i nomi costanti del preprocessore, per indicare che non erano effettivamente variabili.

#define INT_CONST 4 
#define STRING_CONST "Yello." 
#define FLOAT_CONST 3.6122448 

Considerando che questo era l'unico vero modo per definire una vera costante in C (è ancora possibile cambiare const variabili se si sa come), le costanti del preprocessore del genere erano appena visti come costanti, e come tale la il significato dei nomi tutto maiuscolo si è spostato dalle costanti del preprocessore alle semplici costanti in generale. Questo è poi passato nelle lingue successive, diventando la pratica standard "consts = capitali".

Altre lingue hanno il proprio stile preferito, tuttavia (ad esempio, C# & .NET preferisce PascalCase), quindi è generalmente preferibile utilizzare lo stile preferito se ce n'è uno.

Answer 14

In realtà la maggior parte delle linee guida di denominazione C++ (incluso ISO, Boost, Sutter & Stroustrup e Google) scoraggia fortemente le costanti di denominazione con tutte le maiuscole. Questo perché le macro utilizzano anche tutte le maiuscole e possono essere disseminate ovunque nei file di intestazione creando potenzialmente strani comportamenti. Le persone usano comunque tutti i tappi perché imparano dal vecchio C/K & R o dal vecchio codice precedente. Tuttavia, nel nuovo codice C++ moderno, dovresti evitare di usare maiuscole tutte tranne le macro.

La mia teoria del pet per il motivo per cui tutte le maiuscole esiste è che su macchine molto vecchie, il codice veniva immesso direttamente nel codice macchina utilizzando tastiere numeriche. Quando il linguaggio assembly è arrivato sulla scena, ha usato solo maiuscole perché la tastiera in quel momento non era standardizzata e alcune tastiere erano limitate, ad esempio usando gli stessi tastierini numerici per inserire alfabeti come nei feature phone. Questo è stato poi riportato in molte lingue antiche come BASIC, che è tutto maiuscolo. Quando i terminali reali sono diventati disponibili e le tastiere hanno iniziato a essere standardizzate, le persone hanno iniziato a utilizzare casi misti senza prenotazioni e tutte le maiuscole sono state riservate a qualcosa che è raro in presenza di costanti rispetto a funzioni e variabili.

La maggior parte delle linee guida C++ ora concordano sull'uso di "k" come prefisso per costante seguito dal nome con underscore o CamelCase. Personalmente preferisco kCameCase perché consente facilmente di distinguere dalle variabili che sono denominate con under_scores.

const float kFixedRadius = 3.141; 

Answer 15

Non utilizzare ALL_CAPS per le costanti solo perché le costanti di una volta le macro.

Questo quote da C++ Core Guidelines riassume tutto.

Answer 16

Questo è puramente per aiutare il programmatore a capire cosa sta guardando da un colpo d'occhio. È utile sapere che viene utilizzata una costante in modo che il valore non cambi, indipendentemente dal modo in cui ci si riferisce ad esso.

Non c'è davvero una ragione per quanto riguarda il lato compilatore delle cose. Le convenzioni di denominazione sono puramente questo, convenzioni, non restrizioni realmente tecniche.