it-swarm.dev

Gibt es eine gemeinsame Großschreibungskonvention in C ++?

Ich arbeite viel in Python und Java), und beide Sprachen haben ziemlich gemeinsame (wenn auch nicht universelle) Konventionen, wie Groß- und Kleinschreibung in Bezeichnern verwendet werden soll: Beide verwenden PascalCase für Klassennamen und ALL_CAPS für "globale" Konstanten, aber für andere Bezeichner wird viel Java Code verwendet mixedCase, während viel Python Code verwendet underscore_delimiters. Ich weiß, dass keine Sprache oder Bibliothek erzwingt eine bestimmte Großschreibung, aber ich habe das festgestellt, wenn ich mich an die Standardkonventionen für die Sprache I halte Ich benutze, mein Code scheint viel besser lesbar.

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

13
David Z

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

C++ basiert auf C, das alt genug ist, um zum Zeitpunkt der Erfindung von C++ eine ganze Reihe von Namenskonventionen entwickelt zu haben. Dann fügte C++ einige hinzu, und C war auch nicht untätig, 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 C und C++ rückbefruchtet haben ... Mit anderen Worten: C++ hat keine, aber viele solcher Konventionen.

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

Was auch immer Sie verwenden, die wichtigste Regel ist: Seien Sie konsistent!

Interessanterweise habe ich, während ich mit einer Mischung aus PascalCase und camelCase angefangen habe und an zahlreichen Projekten mit noch zahlreicheren Namenskonventionen beteiligt war, im Laufe der Jahre immer mehr an der standard_library_convention festgehalten. Frag mich nicht warum.

27
sbi

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 böse zu sagen.

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

Also, Java hat die Großbuchstabenkonvention für Konstanten aus dem frühen C übernommen. In der Zwischenzeit und vielleicht sogar vorher (ich bin mir der Chronologie hier nicht sicher) hat C Konstanten erhalten Natürlich steckten einige/viele C-Programmierer in der früheren Konvention fest, dass Konstanten als Makros in Großbuchstaben erforderlich waren. C++ - Programmierer waren sinnvoller.

Das große Problem besteht heutzutage darin, dass die Leute zuerst unterrichtet werden Java zuerst oder C (mit Konventionen aus dem Mittelalter)) und dann zu C++ kommen und diese üble Großbuchstaben-Konvention mitnehmen.

Damit,

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

Vielleicht haben Sie gedacht, ich hätte im Scherz Tastaturen nur in Großbuchstaben erwähnt. Ach nein. Denn das ist nur die älteste, archaischste Technologieeinschränkung, die zu Namenskonventionen geführt hat oder zumindest beeinflusst hat, wie falsch/richtig sie erschienen sind. 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. Dort sind wir! Wir sind nicht weiter gekommen.

Derzeit unterstützt Standard-C++ ab 2011 allgemeinen Unicode in Namen (und dies seit 1998), während dies bei tatsächlichen C++ - Implementierungen nicht der Fall ist. Insbesondere der g ++ - Compiler ist nationalem Charakter ausgesetzt. Es ergibt sich aus der technologischen Begrenzung dieses dunklen Zeitalters.

Damit,

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

Zum Thema Unterstriche im Vergleich zu eingestreuten Großbuchstaben

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

Ich denke, das ist es wirklich, mit Ausnahme von Regeln wie "Vermeiden Sie im Allgemeinen Einzelbuchstaben mit Ausnahme von (Schleife, Vorlagenparameter, 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 Unterstrich gefolgt von Großbuchstaben, die zwei aufeinanderfolgende Unterstriche enthalten, oder mit Unterstrich zu beginnen und sich im globalen Namespace zu befinden.

Prost & hth

19

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

Realistisch gesehen ist das Wichtigste jedoch, 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, sollten Sie den bereits vorhandenen Stil verwenden.

2
DeM0nFiRe

Nun, es gibt Systems Hungarian , was auch jetzt noch sehr verbreitet ist, aber ich würde mir lieber die Kehle durchschneiden, als es zu empfehlen. Apps Ungarisch ist besser, da seine Anmerkungszeichen wirklich auf die Semantik hinweisen, obwohl ich der Meinung bin, dass es ein wenig zu scharf auf Abkürzungen ist, wenn ein kurzes Wort ausreichen würde. (Um das Beispiel von dieser Wikipedia-Seite zu verwenden, warum rw für Zeilen verwenden, wenn row nur 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 Personen zu befolgen, mit denen Sie arbeiten . Ja wirklich. Die meisten Konventionen funktionieren gut genug, insbesondere wenn sie konsequent verwendet werden. Inkonsistenz ist am schlimmsten (noch mehr als Systems Hungarian, was ich hasse). Und wenn Sie alleine sind, verwenden Sie, was Sie wollen.

1
Donal Fellows

Soweit ich gesehen habe, variiert es zwischen den Projekten.

Eingebettete Unterstriche werden in C unter Unix wahrscheinlich traditioneller/häufiger verwendet. Die Standardbibliothek folgt ebenfalls diesem Befehl, daher wird sollte mit ziemlicher Sicherheit als Standard behandelt, es sei denn, es ist genügend Code vorhanden, der eine andere Konvention verwendet, um die Verwendung dieser anderen Konvention absolut zu erzwingen.

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

1
Jerry Coffin

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

Die Standardbibliothek verwendet eine Namenskonvention, 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 verwenden. Wenn ich das tue, sehen Makros wie Funktionen aus, wenn sie können. Ich verwende auch konstante Werte oder Aufzählungen anstelle von manifestierten Konstanten, um alle 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
};
1
Bill Door

Diese Referenz beschreibt eine Namenskonvention, die derjenigen 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 vermeiden, der Namenskonvention der C++ Standard Library in meinem eigenen Code zu folgen, wenn auch nur, um Namenskollisionen mit zu vermeiden die Standardbibliothek.

Diese vorherige SO Antwort zu einem verwandten Thema kann auch von Interesse sein: https://stackoverflow.com/questions/228783/what-are-the-rules-about-using -an-Unterstrich-in-AC-Kennung

0
Gnawme