Benennung: Warum sollten benannte Konstanten alle Großbuchstaben in C++/Java sein?

Question

Ich weiß, dass es für C++ und Java eine gut etablierte Namenskonvention ist, dass Konstanten in Großbuchstaben geschrieben werden sollten, mit Unterstrichen, um Wörter zu trennen. Wie dieses (Java-Beispiel):

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

Diese Namensgebung zu verstehen Konvention einfach ist und zu folgen, aber ich frage mich, warum wählt diese Namenskonvention über die normale Namens-Konvention für Variablen:

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

Es scheint nicht nötig zu sein, das Aussehen von Konstanten zu ändern. Wenn wir ihnen einen Wert zuweisen wollen, wird der Compiler dies sowieso verhindern. Tatsächlich macht es Probleme, wenn später die Konstante in eine richtige Variable geändert wird (weil die Farben zum Beispiel konfigurierbar werden).

Also was ist der ultimative Grund, benannte Konstanten in Großbuchstaben zu schreiben? Historische Gründe?

Answer 1

Wahrscheinlich haben Sie Recht. Computer und Compiler (vor allem) waren nicht so schnell wie heute.

Joel Spolsky erwähnt in one of his essays wie beeindruckt er war mit Kompilierungszeit der neuen Version von Turbo Pascal.

Ich erinnere mich, als Zusammenstellung von nicht zu groß Programm (10-20KLOC) mit Overlays in Turbo Pascal 5.0 auf PC XT 10 MHz etwa 20 Minuten in Anspruch nahm ...

Ich nehme an, dass für die Kompilierung warten Fehler zu erkennen war nicht akzeptabel.

Und solche Konvention hilft, Fehler und verschwendete Zeit während der fehlerhaften Kompilierung zu vermeiden.

Answer 2

Ich kann mir vorstellen, dass zunächst zurück in den C Tage, würden die Leute symbolisch „Konstanten“ implementieren, die Pre-Prozessor:

typedef unsigned int Color; 
#define BACKGROUND_COLOR 0xffffff 

Solche „Konstanten“ sind nur prettified Literale, und als solche sind sie verhalten Sie sich nicht ganz so wie Variablen. Sie können zum Beispiel nicht, nehmen Sie die Adresse eines solchen „Konstante“:

Color *p = &BACKGROUND_COLOR; // Breaks! 

Aus diesem Grund ist es sinnvoll, sie „stand out“ zu haben, macht, wie sie sind wirklich nicht nur „Variablen, die Sie kann nicht geändert werden ".

Answer 3

Mit Großbuchstaben Konstante lange Formeln sind viel einfacher zu lesen, müssen Sie nicht erraten, welches Element variieren kann und welche nicht. Es ist natürlich nur eine Konvention, aber hilfreich.

Answer 4

Ich denke, es ist kein technisches, sondern ein psychologisches Problem. Namenskonventionen sind nicht für den Compiler zu verarbeiten (der Computer kümmert sich nicht wirklich um Namen), sondern eher für den Programmierer, der den Code durchsucht, um so viel Information wie möglich mit so wenig Aufwand wie nötig zu haben. Die Verwendung einer anderen Namenskonvention sagt dem Leser deutlich, dass das, was Sie lesen, etwas ist, das zur Kompilierzeit FIXED ist und Sie nicht durch den Code gehen müssen, um zu bestimmen, wo und wie der Wert dorthin gelangt ist.

Answer 5

Wenn ich weiß, dass etwas eine Konstante ist, kann ich mehrere Male darauf verweisen und weiß, dass es sich nicht ändert.Mit anderen Worten, das weiß ich:

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

das gleiche wie:

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

, die nützlich sein kann manchmal zu kennen. Persönlich bevorzuge ich die .NET-Namenskonvention, die Pascal Fall für Konstanten zu verwenden ist (und Methoden):

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

Ich bin kein großer Fan von shouty Fall ... aber ich mag Konstanten offensichtlich Konstanten seines .

Answer 6

Es ist eine Problemumgehung für Ihre Entwicklungswerkzeuge nicht in der Lage, die Eigenschaften eines Bezeichners in einer bequemen Weise zu erkennen.

Ähnlich wie ungarische Notation.

Wenn Ihre IDE besser wird, brauchen Sie keine Namenskonvention, aber diejenige, die vorschreibt, dass ein Name umfassende Informationen darüber ist, was ein Bezeichner bedeutet.

Auch das kann sich entwickeln: warum nicht ein Programmiersystem erstellen, wo Sie nur Kennungen erstellen und fügen Sie Eigenschaften wie "kurze Beschreibung", "type", ... Wenn das Werkzeug ankommt, kann dies bequem tun So, ich bin drin. "Intentional Programming" ist ein Hinweis.

Answer 7

Bei der Programmierung ist es wichtig, einen Code zu erstellen, der für Menschen verständlich ist. Namenskonventionen helfen dabei. Dies ist am besten, wenn Sie Code betrachten, den Sie nicht geschrieben haben, und den Code wartungsfreundlicher macht, da er einfach von Konstanten und Variablen zu unterscheiden ist.

Answer 8

Ich glaube an C++ ist es eine Konvention, die von den Tagen der Verwendung des Präprozessors übernommen wurde, um # konstante Werte zu definieren. Damals wurde es gemacht, um zu vermeiden, dass der Präprozessor seinen gesamten Quellcode mit Füßen tritt, da die üblichen Konventionen für C-Funktion und Variablennamen sie zu Groß- oder Kleinbuchstaben machen würden.

Aus C++ Sicht würde ich sagen, dass es eine schlechte Idee ist, Ihre Konstanten in Großbuchstaben zu machen. Ich musste deshalb mehr als ein Build-Problem debuggen - denken Sie daran, dass der C++ - Präprozessor nichts über Namespaces und den Namensumfang weiß und gerne ersetzen wird, was er für angemessen hält, obwohl es eher unpassend ist.

Answer 9

Codierungskonvertierungen sollen die Lesbarkeit verbessern. Sie müssen keine Buchstaben verwenden. Java erlaubt zum Beispiel $ symbol.

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

Sie könnten Ihre Variablen auch nummerieren, aber das bedeutet nicht, dass es eine gute Idee ist. ;)

Answer 10

Ich denke Großbuchstaben Konstanten sind ein schlechtes Erbe von C. Die Logik dahinter ist die gleiche wie bei der Verwendung von Unterstreichungen als Präfixe für private Mitglieder. Dies ist technisches Zeug, das bereits durch Java-Schlüsselwörter wie private oder im Falle von Konstanten static final ausgedrückt wird.

Siehe auch: http://weblogs.java.net/blog/2006/09/28/case-against-uppercases

Answer 11

In C (und dann C++), Symbole, die mit dem Präprozessor #define Richtlinie definiert wurden, wurden alle in den Schutzkappen als ein lautes Signal an Entwickler geschrieben, dass der Code war nicht, wie es schien, und nicht als normales Symbol behandeln. Konstanten gab es anfänglich nicht in K & R C (obwohl const später von C++ zurückgebracht wurde), so verwendeten die Entwickler stattdessen #define, daher die Kappen.

Aus irgendeinem Grund wurde dies in Java als "Konstanten sind Caps" verdreht, daher die aktuelle fehlgeleitete (IMO) Konvention.

Answer 12

Es ist definitiv ein technisches Problem in Java. Überlegen Sie:

Was ist der Wert von "whatAmI" vor und nach dem Auskommentieren der vorherigen Zeile?

Wenn der Konstantenname dieselbe Konvention wie der Name der lokalen Variablen hat, führt dies zu REAL-Code-Problemen. Konstanten sollten immer die UPPERCASE-Konvention haben, um dies zu vermeiden.

Answer 13

Im Grunde, zurück, als Menschen in C verliebt waren, und C++ & Java waren entweder neu oder noch nicht erstellt, Leute verwendeten alle Großbuchstaben für Preprozessor-Konstantennamen, um anzuzeigen, dass sie nicht tatsächlich Variablen waren.

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

bedenkt, dass dies der einzige Weg war, eine wahre Konstante in C (es ist immer noch möglich const Variablen zu ändern, wenn Sie wissen, wie) zu definieren, Präprozessorkonstanten so wurden nur als Konstanten gesehen, und als solche der Bedeutung von All-Caps-Namen, die von Präprozessor-Konstanten zu einfachen Konstanten im Allgemeinen verschoben sind. Dies wurde dann in spätere Sprachen übertragen und wurde zum Standard "costs = capitals".

Andere Sprachen haben jedoch ihren eigenen bevorzugten Stil (zum Beispiel C# &. NET bevorzugen PascalCase), also ist es am besten, den bevorzugten Stil zu verwenden, wenn es einen gibt.

Answer 14

Eigentlich rät die meisten C++ Benennungsrichtlinien (einschließlich ISO, Boost, Sutter & Stroustrup und Google) stark davon ab, Konstanten mit Großbuchstaben zu benennen. Dies liegt daran, dass Makros auch Großbuchstaben verwenden und sie überall in Header-Dateien verstreut sein können, was möglicherweise seltsame Verhaltensweisen erzeugt. Die Leute benutzen immer noch alle Caps, weil sie von altem C/K & R oder altem Legacy-Code lernen. In Modern C++ - neuem Code sollten Sie jedoch vermeiden, Großbuchstaben für alles außer Makros zu verwenden.

Meine Lieblingstheorie, warum überhaupt Caps existieren, ist, dass bei sehr alten Maschinen der Code direkt im Maschinencode über numerische Tastaturen eingegeben wurde. Wenn die Assemblersprache in der Szene eintraf, verwendete sie nur Großbuchstaben, da die Tastatur zu dieser Zeit nicht standardisiert war und einige Tastaturen eingeschränkt waren, zum Beispiel mit den gleichen numerischen Tastenfeldern, um in Alphabete wie in Funktionstelefone einzutreten. Dies wurde dann auf viele frühe Sprachen wie BASIC übertragen, was alles ist, was alles abdeckt. Als die tatsächlichen Terminals verfügbar wurden und die Tastaturen standardisiert wurden, begannen die Leute, gemischte Fälle ohne Vorbehalte zu verwenden, und alle Großbuchstaben wurden für etwas reserviert, das im Vergleich zu Funktionen und Variablen selten vorkommt.

Die meisten C++ - Richtlinien stimmen nun darin überein, "k" als Präfix für Konstante gefolgt von Name mit Unterstrich oder CamelCase zu verwenden. Ich persönlich bevorzuge kCameCase, weil es leicht erlaubt, von Variablen zu unterscheiden, die mit under_scores benannt sind.

const float kFixedRadius = 3.141; 

Answer 15

Sie ALL_CAPS nicht für Konstanten verwenden, nur weil Konstanten Makros verwendet werden soll.

Diese quote von C++ Core-Richtlinien fasst alles zusammen.

Answer 16

Dies hilft dem Programmierer zu verstehen, was er auf einen Blick sieht. Es hilft zu wissen, dass eine Konstante verwendet wird, so dass der Wert sich nicht ändert, egal wie Sie darauf Bezug nehmen.

Es gibt nicht wirklich einen Grund in Bezug auf die Compiler-Seite der Dinge. Namenskonventionen sind rein, Konventionen, nicht wirklich technische Restriktionen.