Gibt es in C ++ eine gemeinsame Großschreibung? [geschlossen]


13

Ich arbeite viel in Python und Java, und beide Sprachen haben ziemlich gemeinsame (wenn auch nicht universelle) Konventionen, wie die Großschreibung in Bezeichnern verwendet werden soll: sowohl PascalCasefür Klassennamen als auch ALL_CAPSfür "globale" Konstanten, aber für andere Bezeichner a Viele Java-Codes werden verwendet, mixedCasewohingegen viele Python-Codes verwendet werden underscore_delimiters. Ich weiß, dass keine Sprache oder Bibliothek eine bestimmte Groß- oder Kleinschreibung erzwingt , aber ich habe festgestellt, dass mein Code viel besser lesbar erscheint, wenn ich mich an die Standardkonventionen für die von mir verwendete Sprache halte.

Jetzt starte ich ein Projekt in C ++ und möchte dieselbe Idee anwenden. Gibt es eine gängige Konvention für die Großschreibung, über die ich Bescheid wissen sollte?


Das Problem mit camelCase ist, dass es mit dem Präprozessor nicht gut funktioniert. Kein großes Problem, zumal der Präprozessor in der Regel vermieden werden kann.
Pubby

Vor ein paar Tagen musste ich mich dieser Entscheidung stellen. Am Ende war es ein Kinderspiel, da sowohl die Standardbibliothek als auch Boost Underscore_lowercase_delimiters verwenden. Da ich boost als STL-Booster benutze, wird alles über meinen Code gestreut. Andere Bibliotheken, die ich verwende, sind PascalCase (SFML). Sie können einfacher enthalten sein, sodass jede Methode ziemlich standardisiert ist.
Max

@ Pubby8: aus neugier: wie kollidiert camelCase mit dem präprozessor?
Joachim Sauer

@JoachimSauer Einzelne Wörter in camelCase haben möglicherweise eine andere Groß- / Kleinschreibung, aber Makros können die Groß- / Kleinschreibung nicht ändern. Dies ist problematisch, wenn Sie ein Makro verwenden möchten, das einen Teil eines Wortes als Argument verwendet. Möglicherweise müssen Sie beide Fälle als Argumente angeben: macro (x, X). Es ist ein ziemlich kleines Problem, sollte aber bekannt sein, wenn Sie beabsichtigen, den Präprozessor zu verwenden.
Pubby

Antworten:


27

Gibt es eine gängige Konvention für die Großschreibung, über die ich Bescheid wissen sollte?

C ++ basiert auf C, das alt genug ist, um eine ganze Reihe von Namenskonventionen zu entwickeln, als C ++ erfunden wurde. Dann fügte C ++ einige hinzu, und C war auch nicht müde, an neue zu denken. Hinzu kommen die vielen C-abgeleiteten Sprachen, die die C-Namenskonventionen ihres Erfinders weiterentwickelt haben, bis zu dem Punkt, an dem sie sich auf C und C ++ rückdüngten ... Mit anderen Worten: C ++ hat keine, aber viele solcher Konventionen.

Wenn Sie jedoch nach einer Namenskonvention suchen , können Sie sich auch die Namenskonvention der Standardbibliothek ansehen , da dies die einzige ist, die alle C ++ - Entwickler kennen und gewohnt sein müssen.

Was auch immer Sie als wichtigste Regel verwenden: Seien Sie konsequent!

Interessanterweise habe ich mich im Laufe der Jahre immer mehr mit der standard_library_convention beschäftigt, als ich mit einer Mischung aus PascalCase und camelCase begann und an zahlreichen Projekten mit noch mehr Namenskonventionen beteiligt war. Frag mich nicht warum.


Danke für die Info ... also ist die Standardbibliothek dann unterstrichen? (Zumindest mehr als alles andere?) Ich habe in diese Richtung gedacht, aber es war etwas schwer zu sagen, weil es sich bei der Hälfte der Methodennamen anscheinend um die gleichen zusammengedrückten Wortfragmente wie bei ANSI handelt C :-P
David Z

5
@David: Die iostreams-Bibliothek ist wahrscheinlich 25 Jahre alt und (mit Ausnahme der C-Bibliothek oder des Kurses) möglicherweise der älteste Teil der C ++ - Standardbibliothek. Hoffentlich würde niemand, der bei Verstand ist, es so gestalten, wie es heutzutage ist, und hoffentlich würden auch diejenigen, die nicht bei Verstand sind, keine Bezeichner auswählen, wie sie in der Streams-Bibliothek verwendet werden. (C'mon, gibt es Funktionen genannt egptr, sputnund uflowals auch underflow. Das ist einfach urkomisch!) Wie auch immer, ja, die std lib all_lowercase_with_underscores heute verwendet.
sbi

@sbi Ich habe herausgefunden, dass die iostream-Bibliothek keine Standardbibliothek für C ++ mehr ist. Und wie Sie bereits erwähnt haben, sind seine Bezeichner als Programmierkonvention nicht nützlich
;-)

2
@umlcat: Die iostreams-Bibliothek (in der Vorlage für C ++ 03) wird definitiv als Teil der C ++ - Standardbibliothek betrachtet.
sbi

Ich bin den gleichen Weg gegangen. Ich denke, der Grund, den ich habe, ist, dass camelCase etwas einfacher zu tippen ist und ich wollte dort faul sein. Später erfuhr ich, dass ich mehr Zeit damit verbracht habe, meinen Code zu lesen und zu überarbeiten als ihn zu schreiben, und snake_case ist einfacher zu lesen. Es geht also darum, den Energieverbrauch zu minimieren. Jetzt spiele ich mit der Verwendung von Kleinbuchstaben für Klassen. Es ist unkonventionell, aber ich denke, dass es die Lesbarkeit meines Codes verbessert, wenn wichtige Instanzen vertauscht und Typen vertauscht werden. Ich denke, vielleicht ist dies der richtige Weg. Großschreibung, was wichtig ist, wie in Humanesisch.
PSkocik

19

Lassen Sie uns zunächst zustimmen, dass ALL UPPERCASE ein Dorn im Auge ist und minimiert werden sollte.

In C und C ++ wird es daher als Konvention für Makros und nur für Makros verwendet, da Makros ebenso hässlich sind, um nicht zu sagen böse.

Frühes C hatte keine Konstante, also mussten Konstanten als Makros ausgedrückt werden. In jenen frühen Tagen waren die Programme auch viel kürzer, so dass die heute unguten Praktiken angewendet werden konnten (z. B. schrieb IIRC Brian Kernighan Code mit vielen Nicht-Großbuchstaben-Makros). Zu jener Zeit gab es Tastaturen ohne Kleinbuchstaben. Ich habe einen solchen auf dem norwegischen Tandberg EC-10-Computer verwendet, ungefähr 1980 oder 1979, glaube ich.

Java hat also die Konvention für Konstanten in Großbuchstaben von Anfang C aufgegriffen. In der Zwischenzeit und vielleicht sogar vorher (ich bin mir der Chronologie hier nicht sicher) hat C Konstanten bekommen. Während natürlich einige / viele C-Programmierer in der früheren Konvention der Notwendigkeit von Konstanten als Großbuchstabenmakros feststeckten, waren C ++ - Programmierer vernünftiger.

Das große Problem besteht heutzutage darin, dass den Menschen zuerst Java oder C (mit Konventionen aus dem Mittelalter) beigebracht wird und sie dann zu C ++ kommen und diese unlauteren Konventionen in Großbuchstaben mitnehmen.

So,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Nun, Sie hätten vielleicht gedacht, ich hätte im Scherz nur Tastaturen mit Großbuchstaben erwähnt. Ach nein. Denn das ist nur die älteste, archaischste Technologie-Einschränkung, die Namenskonventionen hervorgerufen oder zumindest beeinflusst hat, wie falsch / richtig sie ausgesehen haben. Als nächstes gab es das Problem der seriellen 7-Bit-Übertragung, das entsprechende Probleme mit den verwendeten Zeichencodes (Newspeak-Zeichencodierungen) verursachte, was bedeutete, dass Sie sich auf die Buchstaben des englischen Alphabets A bis Z beschränken mussten.

Eigentlich empfehle ich das immer noch zu tun. Da sind wir! Wir sind nicht weiter gekommen.

Gegenwärtig unterstützt Standard-C ++ ab 2011 allgemeines Unicode in Namen (und dies seit 1998), während dies bei tatsächlichen C ++ - Implementierungen nicht der Fall ist. Insbesondere der g ++ Compiler ist national geprägt. Es stammt aus dieser technologischen Einschränkung des dunklen Zeitalters.

So,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Schließlich zum Thema Unterstriche im Vergleich zu eingestreuten Großbuchstaben:

  • Reservieren Sie ein leicht zu erkennendes Formular für Typnamen.
  • Reservieren Sie ALLE GROSSBUCHSTABEN für Makros.
  • Seien Sie konsequent.

Ich denke, das ist es wirklich, abgesehen von Regeln wie "Vermeiden Sie generell Namen mit einem Buchstaben außer (Schleife, Template-Parameter, bla bla)" und "Vermeiden Sie die Verwendung von l, leicht zu verwechseln mit 1" und "Vermeiden Sie Großbuchstaben O, leicht zu verwechseln" mit 0 ". Vermeiden Sie es natürlich auch, reservierte Namen zu verwenden, z. B. mit einem Unterstrich gefolgt von einem Großbuchstaben, der zwei aufeinanderfolgende Unterstriche enthält, oder mit einem Unterstrich zu beginnen und sich im globalen Namespace zu befinden.

Prost & Hth


Alf, ISTR Stroustrup erwähnte in D & E C das Kopieren constvon C ++, also musste dies vor sehr langer Zeit geschehen sein und lange vor Java, wahrscheinlich für C89.
sbi

2
Oh, und ein Herz +1für "Sei konsequent!" Ich frage mich, warum ich vergessen habe, diese wichtigste Regel in meiner Antwort zu erwähnen, als es die war, die ich nie vergessen habe, meinen Schülern mitzuteilen. Ich nehme an, Sie werden mir vergeben, wenn ich es jetzt als nachträglicher Gedanke zu meiner Antwort hinzufüge?
sbi

2

Normalerweise halte ich mich an die Konvention, die ich in vorhandenen Codebasen für die Sprache am häufigsten sehe. Im Fall von C ++ sehe ich normalerweise camelCase. Im Falle von Ruby oder PHP sehe ich normalerweise stuff_like_this.

Realistisch gesehen ist es jedoch am wichtigsten, dass Sie eine Stilkonvention auswählen, die nicht völlig verrückt ist (dOnT_dO_tHiS) und mit dieser übereinstimmt. Stellen Sie sicher, dass sich der Stil im gesamten Code für ein bestimmtes Projekt nicht ändert. Wenn Sie an einem vorhandenen Projekt arbeiten, möchten Sie den bereits vorhandenen Stil verwenden.


1

Nun, es gibt Systeme ungarischen, die auch jetzt noch sehr verbreitet sind, aber ich würde lieber meine eigene Kehle durchschneiden, als es zu empfehlen. Apps Hungarian ist besser, da die Beschriftungszeichen wirklich auf die Semantik hinweisen, obwohl ich der Meinung bin, dass es ein wenig zu scharf auf Abkürzungen ist, wenn ein kurzes Wort genügen würde. (Um das Beispiel von dieser Wikipedia-Seite zu verwenden, warum rwfür Zeile verwenden, wenn rownur ein Zeichen länger ist? Es ist nicht so, als gäbe es einen globalen Vokalmangel.)

Realistisch gesehen ist es jedoch am wichtigsten, die Konventionen der Menschen zu befolgen , mit denen Sie zusammenarbeiten . Ja wirklich. Die meisten Konventionen funktionieren gut genug, besonders wenn sie konsequent verwendet werden. Inkonsistenzen sind am schlimmsten (noch schlimmer als bei ungarischen Systemen, die ich hasse). Und wenn Sie alleine sind, verwenden Sie, was Sie wollen.


1

Nach dem, was ich gesehen habe, variiert es zwischen den Projekten.

Eingebettete Unterstriche werden in C unter Unix wahrscheinlich traditioneller bzw. häufiger verwendet. Darauf folgt auch die Standardbibliothek, daher sollte sie mit ziemlicher Sicherheit als Standard verwendet werden, es sei denn, es ist genügend Code vorhanden, der eine andere Konvention verwendet, um die Verwendung dieser anderen Konvention zu erzwingen.

Windows (zum Beispiel) verwendet Camel Case für die meisten seiner Funktionen, so dass nicht wenige Leute, die für Windows entwickeln, dasselbe tun. Dies ist auch ziemlich häufig bei Leuten, die wirklich an andere Sprachen gewöhnt sind und versuchen, C ++ so zu behandeln, als ob es nur eine seltsame Variante von etwas anderem wäre.


1

Ich habe sowohl Standardbibliothek als auch Boost als Referenz für Namenskonventionen verwendet. Es gibt jedoch ein Problem mit dieser Lösung.

In der Standardbibliothek wird eine Namenskonvention verwendet, mit der versucht wird, Kollisionen mit Ihrem Code zu reduzieren. Ein Teil der Lösung besteht darin, alle Kleinbuchstaben zu verwenden. Daher die Verwendung von Unterstrichen anstelle von camelCase.

Ich finde, dass camelCase lesbar ist. PascalCase wird häufig für Klassennamen verwendet, da es das Äquivalent eines Eigennamens darstellt. Ich werde diese Regel jedoch für Funktoren brechen, die repräsentativer für ein Verb sind.

Ich versuche keine Makros zu benutzen. Wenn ich das tue, werden Makros so erstellt, dass sie wie Funktionen aussehen, wenn sie können. Ich verwende auch const-Werte oder Aufzählungen anstelle von manifesten Konstanten, um weiterhin Großbuchstaben zu vermeiden. Normalerweise stelle ich diesen Symbolen ein "k" voran, um anzuzeigen, dass sie konstant sind.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

0

Diese Referenz beschreibt eine Namenskonvention, die denen ziemlich ähnlich ist, die ich in mindestens drei Unternehmen, für die ich in der Vergangenheit gearbeitet habe, mit Erfolg verwendet habe.

Im Gegensatz zu einer früheren Antwort würde ich es vermeiden, die Namenskonvention der C ++ - Standardbibliothek in meinem eigenen Code zu befolgen, wenn auch nur, um Namenskollisionen mit der Standardbibliothek zu vermeiden.

Diese vorherige SO-Antwort zu einem verwandten Thema ist möglicherweise auch von Interesse: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier


Umm, Sie können dieselbe Namenskonvention verwenden, ohne dieselben Namen zu verwenden ... und wenn Sie wirklich dieselben Namen möchten, sind Sie dennoch durch Namespaces geschützt, z . B. std::stringvs. gnawme::string
Einpoklum
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.