Wie Sie allgemeine C++ - Namenskonventionen mit denen der Bibliotheken abgleichen

Question

Die meisten C++ - Namenskonventionen schreiben die Verwendung von camelCaseIdentifiers vor: Namen, die mit einem Großbuchstaben für Klassen beginnen (Person, Booking) und Namen, die mit einem Kleinbuchstaben für Felder beginnen und Variablen (getPrice(),, largestValue). Diese Empfehlungen sind vollständig im Widerspruch zu den Namenskonventionen der C++ Bibliothek, die für die Klassen klein geschriebene Namen beinhalten (string, set, map, fstream) und names_joined_with_an_underscore für Methoden und Felder (find_first_of, lower_bound, reverse_iterator, first_type). Weitere Komplikationen sind die Betriebssystem- und C-Bibliotheksfunktionen, die komprimierte Kleinbuchstaben in C und Unix enthalten und Funktionen, die mit einem Großbuchstaben in Windows beginnen.

Als Ergebnis ist mein Code ein Chaos, weil einige Bezeichner die C++ - Bibliothek, C oder Betriebssystembenennungskonvention verwenden und andere die vorgeschriebene C++ - Konvention verwenden. Das Schreiben von Klassen oder Methoden, die die Funktionalität der Bibliothek umhüllen, ist schmerzhaft, weil man mit ähnlichen Namen für ähnliche Dinge endet.

Also, wie vereinbaren Sie diese unterschiedlichen Namenskonventionen?

Answer 1

Ein Weg, um die C++ naming_convention zu übernehmen, das ist, was die meisten Codebeispiele in der Literatur heutzutage tun.

Ich sehe langsam diese Konventionen in Produktionscode bewegen, aber es ist ein Kampf gegen MFC Namenskonventionen, die immer noch an vielen Orten vorherrschen.

Andere Stilunterschiede, die gegen alte Standards verstoßen, verwenden nachgestellte Unterstriche statt m_, um Elemente zu bezeichnen.

Answer 2

Ich bin ein Perfektionist, wenn es um Code-Stil geht, und das hat mich immer gestört. Ich wünschte, es gäbe einen universellen Standard, aber das ist nicht der Fall. In meiner beruflichen Laufbahn habe ich festgestellt, dass, solange die Programmierer eines einzelnen Projekts konsistent sind, dies das Beste ist, auf das man hoffen kann.

Letztendlich kommt es darauf an zu wissen, aus welcher Bibliothek eine Methode, ein Objekt oder eine Funktion stammt. Wenn Sie das wissen, wird es leicht genug, sich daran zu erinnern, welche Konvention von dieser Bibliothek verwendet wird, vorausgesetzt, das Projekt enthält nicht viele Bibliotheken. Ich habe versucht, meinen eigenen Code an den der Bibliotheken anzupassen, die ich verwende, aber er ist immer ein bewegliches Ziel und am Ende frustrierend.

Answer 3

Warum die Notwendigkeit zu versöhnen? Solange der Code kompiliert und Sie die Arbeit erledigen können, machen Sie sich keine Sorgen.

Answer 4

Fav Zitat ::

Das Beste an Standards ist, dass es so viele zur Auswahl!

Mein Vorschlag wäre, die Bibliothek der Konvention zu nehmen, die am häufigsten in Ihrer Firma Code auftritt (wahrscheinlich die C++ Bibliothek, die ich Sticks als auch glauben steigern) und dass Ihren Standard. Ansonsten könntest du auch gar keinen haben.

Answer 5

In den Projekten, an denen ich arbeite, folge ich den Konventionen für mein Projekt. Wenn ich etwas anderes anrufe, benutze ich API dieser Bibliothek.

Ich würde auch hinzufügen, dass das Einpacken der Bibliothek eine schlechte Idee ist (es gibt viele von ihnen in der Code-Basis, an der ich arbeite), weil es normalerweise vom Entwickler gemacht wird, der sein eigenes Problem löst und in der Regel es ist für die Verwendung durch alle anderen Entwickler ungeeignet. Von der anderen Seite ist eine hochwertige Verpackung teuer.

Answer 6

Diomidis, ich teile deine Schmerzen und habe viel Zeit damit verbracht, zwischen verschiedenen Schemata umzuschalten, um etwas zu finden, das mit den verschiedenen Bibliotheken/Frameworks funktioniert, die ich benutze (MFC und/oder STL/Boost). Wenn Sie mit einem einzelnen Framework wie der STL arbeiten, können Sie versuchen, die verwendete Namenskonvention zu kopieren. Wenn Sie jedoch ein anderes Framework einführen, fällt es leicht auseinander.

Am Ende habe ich einen einzigen Stil für alle neuen Code angenommen haben, dass ich (auf der Basis der Google C++ Stil-Richtlinien) und ich Refactoring älteren Code diesen Stil zu verwenden, wenn angemessen schreiben. Sie können die verschiedenen Namenskonventionen nicht einfach miteinander abstimmen, also verschwenden Sie keine Zeit mit dem Versuch. Erzwingen Sie ein Schema für Ihr Team/Abteilung/Unternehmen und bleiben Sie dabei - aber lassen Sie sich nicht davon abhalten, wie "hässlich" der Code aussehen könnte, wenn Sie eine Mischung aus Schemata verwenden.

Die Richtlinien Google C++ sind ziemlich gut IMHO - mit einigen geringfügigen Änderungen. Lesen Sie die Anleitung hier ansehen:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Answer 7

Nun, da wir nicht die Art, wie die Standardbibliotheken implementiert ändern können, denke ich, dass wir mit ihm leben müssen. Zur Abstimmung - beim Schreiben einiger Win32-API-Sachen vor einiger Zeit habe ich versucht, meine eigenen Methoden in PascalCasing zu benennen, wie es in der API gemacht wird, aber es fühlte sich einfach nicht richtig an. Also habe ich meine Methoden in camelCase umbenannt. Ich stimme zu, dass es ein Durcheinander ist, aber die andere Möglichkeit besteht darin, Ihren Stil an jedes neue Framework oder jede Bibliothek anzupassen, und dann gibt es das Problem, dass Sie erwähnen, dass mehr als eine Bibliothek unterschiedliche Konventionen in einem Projekt verwendet. Mein Rat ist also: Bleibe bei dem, was sich für deine eigenen Methoden und Klassen gut anfühlt. Oder - wenn Sie sich in einem Unternehmensumfeld befinden - halten Sie sich an die Best Practices und Richtlinien Ihres Unternehmens.

Answer 8

Ich scheine eine lange Zeit mit dem Lesen vor, daran zu erinnern, dass sie wählen, die Standard-Bibliothek unterscheidet sich von der empfohlenen Codierung Konvention absichtlich zu machen, Kollisionen Namensgebung zu vermeiden. Ich kann jedoch keinen Hinweis finden, der das jetzt erwähnt. Ich erinnere mich zu lesen, dass Sie keine führenden Kleinbuchstaben in Typnamen verwenden sollten, da sie für die Standardbibliotheken reserviert waren. Ich nehme an, dass etwas Ähnliches mit der Verwendung von Unterstrichen geschieht. Ich sehe wirklich nicht mehrere Namenskonventionen als ein Problem, da es den Standardcode klar von Code in Ihrem Projekt trennt. Ich kodiere immer Sachen in meinen Projekten, indem ich camel case für Typen und low camel case für Methoden/Mitglieder verwende. Mein derzeitiger Arbeitsplatz benutzt neben den Typen auch Methoden für den Kapitalkamel, was mich sehr ärgert. Aber sie sehen auch ungarische Warzen, die selbst MS verleugnet hat: P

Answer 9

Ehrlich gesagt, würde ich nur die Bibliothek, wie sie ist, und halten Sie sich an Ihren eigenen Programmierstil. Sie könnte wickeln Sie es, aber das scheint wie Overkill.

Answer 10

Sie sollten den Unterschied begrüßen.

Wenn die Menschen die Verwendung von remove_copy_if sehen, wissen sie sofort, dass dies ein Algorithmus ist. Dies ist tatsächlich eine positive Eigenschaft, da Algorithmen mit bestimmten Garantien (oder Mangel an) kommen.

Wir verwenden auch die Namenskonvention für unsere eigene Algorithmen.