Nach dies Stack Overflow Antwort , das "_t" Postfix für Typnamen ist in C reserviert. Wenn ich typedef benutze, um einen neuen Opaque Type zu erstellen, bin ich es gewohnt, eine Art Hinweis darauf zu haben, dass dies ein a ist Art. Normalerweise würde ich mit etwas wie hashmap_t gehen, aber jetzt brauche ich etwas anderes.
Gibt es ein Standardbenennungsschema für Typen in C? In anderen Sprachen ist die Verwendung von CapsCase wie Hashmap üblich, aber eine Menge C-Code, den ich sehe, verwendet überhaupt keinen Großbuchstaben. CapsCase funktioniert auch ziemlich gut mit einem Bibliotheks-Präfix wie XYHashmap .
Gibt es also eine allgemeine Regel oder einen Standard für die Benennung von Typen in C?
Ja, POSIX reserviert Namen, die auf _t enden, wenn Sie einen der POSIX-Header hinzufügen, also sollten Sie sich von denen fernhalten - theoretisch. Ich arbeite an einem Projekt, das in den letzten zwanzig Jahren zwei oder drei Mal mit solchen Namen in Konflikt geraten ist. Sie können das Risiko einer Kollision minimieren, indem Sie ein Unternehmenspräfix (z. B. die TLA Ihres Unternehmens und einen Unterstrich) oder gemischte Groß- / Kleinschreibung verwenden (sowie das Suffix _t ). Alle Kollisionen, die ich gesehen habe, waren kurz und nur in Kleinbuchstaben ( dec_t , loc_t , ...).
Außer dem vom System bereitgestellten (und vom System reservierten) _t -Suffix gibt es keine spezifische, weit verbreitete Konvention. Eines der gemischten Systeme (camelCase oder InitialCaps) funktioniert gut. Ein systematisches Präfix funktioniert auch gut - die besseren Bibliotheken tendieren dazu vorsichtig zu sein.
Wenn Sie sich für die Verwendung von Kleinbuchstaben und _t Suffix entscheiden, stellen Sie sicher, dass Sie ausreichend lange Namen verwenden und sorgfältig den POSIX-Standard, die primären Plattformen, an denen Sie arbeiten, und alle, an denen Sie arbeiten, überprüfen um unnötige Konflikte zu vermeiden. Die schlimmsten Probleme treten auf, wenn Sie einen Namen example_t an Kunden freigeben und dann feststellen, dass auf einer neuen Plattform ein Konflikt auftritt. Dann müssen Sie darüber nachdenken, Kunden dazu zu bringen, ihren Code zu ändern, was sie immer widerwillig tun. Es ist besser, das Problem im Voraus zu vermeiden.
Die Richtlinien für den indischen Hill-Stil haben einige Vorschläge:
Zweifelsohne haben einzelne Projekte ihre eigenen Namenskonventionen. Dort sind jedoch einige allgemeine Regeln.
Namen mit führenden und abschließenden Unterstrichen sind für das System reserviert Zwecke und sollte nicht verwendet werden für alle benutzerdefinierten Namen. Die meisten Systeme Verwenden Sie sie für Namen, die der Benutzer sollte nicht wissen müssen. Wenn du musst habe deine eigenen privaten Identifikatoren, Beginne sie mit einem oder zwei Buchstaben Identifizieren des Pakets, zu dem sie gehören gehören.
#defineKonstanten sollten in allen CAPS sein.Enum-Konstanten sind aktiviert oder in allen CAPS
Funktion, typedef und Variablennamen sowie struct, union und Enum-Tag-Namen sollten niedriger sein Fall.
Viele Makro "Funktionen" sind in allen CAPS. Einige Makros (wie getchar und putchar) sind in Kleinbuchstaben, da sie kann auch als Funktionen existieren. Kleingeschriebene Makronamen sind nur akzeptabel, wenn sich die Makros wie a verhalten Funktionsaufruf, dh sie werten aus ihre Parameter genau einmal und tun Weisen Sie benannten Parametern keine Werte zu. Manchmal ist es unmöglich, ein zu schreiben Makro, das sich wie eine Funktion verhält obwohl die Argumente sind einmal genau ausgewertet.
Vermeiden Sie Namen, die sich nur im Fall unterscheiden, wie foo und Foo. Ähnlich, vermeide foobar und foo_bar. Das Möglichkeit zur Verwirrung ist beträchtlich.
Vermeiden Sie auf ähnliche Weise Namen, die ähnlich aussehen. Auf vielen Terminals und Drucker, 'l', '1' und 'I' sehen ziemlich aus ähnlich. Eine Variable namens 'l' ist besonders schlecht, weil es so aussieht ähnlich wie die Konstante '1'.
Im Allgemeinen werden globale Namen (einschließlich enums) sollte ein gemeinsames Präfix haben Identifizieren des Moduls, das sie gehören mit. Globals können alternativ in einer globalen Struktur gruppiert sein. Typedeffed Namen haben oft "_t" an ihren Namen angehängt.
Vermeiden Sie Namen, mit denen Konflikte auftreten könnten verschiedene Standardbibliotheksnamen. Etwas Systeme enthalten mehr Bibliothekscode als du willst. Auch Ihr Programm darf eines Tages verlängert werden.
C reserviert nur einige Verwendungen eines _t Suffixes. Soweit ich das beurteilen kann, sind dies nur aktuelle Bezeichner, die mit _t und einem Bezeichner enden, der int oder uint (7.26.8) startet. POSIX reserviert jedoch möglicherweise mehr.
Es ist ein allgemeines Problem in C, da Sie extrem flache Namespaces haben, und es gibt keine Wunderwaffe. Wenn Sie mit CapCase-Namen vertraut sind und diese für Sie gut funktionieren, sollten Sie sie weiterhin verwenden. Andernfalls müssen Sie die Ziele des aktuellen Projekts bewerten und herausfinden, welche Lösung am besten zutrifft sie.
Ja, POSIX reserviert Namen, die auf GtkButton enden, wenn Sie einen der POSIX-Header hinzufügen, also sollten Sie sich von denen fernhalten - theoretisch. Ich arbeite an einem Projekt, das in den letzten zwanzig Jahren zwei oder drei Mal mit solchen Namen in Konflikt geraten ist. Sie können das Risiko einer Kollision minimieren, indem Sie ein Unternehmenspräfix (z. B. die TLA Ihres Unternehmens und einen Unterstrich) oder gemischte Groß- / Kleinschreibung verwenden (sowie das Suffix ClutterStageWindow ). Alle Kollisionen, die ich gesehen habe, waren kurz und nur in Kleinbuchstaben ( clutter_actor_get_geometry() , %code% , ...).
Außer dem vom System bereitgestellten (und vom System reservierten) %code% -Suffix gibt es keine spezifische, weit verbreitete Konvention. Eines der gemischten Systeme (camelCase oder InitialCaps) funktioniert gut. Ein systematisches Präfix funktioniert auch gut - die besseren Bibliotheken tendieren dazu vorsichtig zu sein.
Wenn Sie sich für die Verwendung von Kleinbuchstaben und %code% Suffix entscheiden, stellen Sie sicher, dass Sie ausreichend lange Namen verwenden und sorgfältig den POSIX-Standard, die primären Plattformen, an denen Sie arbeiten, und alle, an denen Sie arbeiten, überprüfen um unnötige Konflikte zu vermeiden. Die schlimmsten Probleme treten auf, wenn Sie einen Namen %code% an Kunden freigeben und dann feststellen, dass auf einer neuen Plattform ein Konflikt auftritt. Dann müssen Sie darüber nachdenken, Kunden dazu zu bringen, ihren Code zu ändern, was sie immer widerwillig tun. Es ist besser, das Problem im Voraus zu vermeiden.
Die Richtlinien für den indischen Hill-Stil haben einige Vorschläge:
Zweifelsohne haben einzelne Projekte ihre eigenen Namenskonventionen. Dort sind jedoch einige allgemeine Regeln.
Namen mit führenden und abschließenden Unterstrichen sind für das System reserviert Zwecke und sollte nicht verwendet werden für alle benutzerdefinierten Namen. Die meisten Systeme Verwenden Sie sie für Namen, die der Benutzer sollte nicht wissen müssen. Wenn du musst habe deine eigenen privaten Identifikatoren, Beginne sie mit einem oder zwei Buchstaben Identifizieren des Pakets, zu dem sie gehören gehören.
%code% Konstanten sollten in allen CAPS sein.
Enum-Konstanten sind aktiviert oder in allen CAPS
Funktion, typedef und Variablennamen sowie struct, union und Enum-Tag-Namen sollten niedriger sein Fall.
Viele Makro "Funktionen" sind in allen CAPS. Einige Makros (wie getchar und putchar) sind in Kleinbuchstaben, da sie kann auch als Funktionen existieren. Kleingeschriebene Makronamen sind nur akzeptabel, wenn sich die Makros wie a verhalten Funktionsaufruf, dh sie werten aus ihre Parameter genau einmal und tun Weisen Sie benannten Parametern keine Werte zu. Manchmal ist es unmöglich, ein zu schreiben Makro, das sich wie eine Funktion verhält obwohl die Argumente sind einmal genau ausgewertet.
Vermeiden Sie Namen, die sich nur im Fall unterscheiden, wie foo und Foo. Ähnlich, vermeide foobar und foo_bar. Das Möglichkeit zur Verwirrung ist beträchtlich.
Vermeiden Sie auf ähnliche Weise Namen, die ähnlich aussehen. Auf vielen Terminals und Drucker, 'l', '1' und 'I' sehen ziemlich aus ähnlich. Eine Variable namens 'l' ist besonders schlecht, weil es so aussieht ähnlich wie die Konstante '1'.
Im Allgemeinen werden globale Namen (einschließlich enums) sollte ein gemeinsames Präfix haben Identifizieren des Moduls, das sie gehören mit. Globals können alternativ in einer globalen Struktur gruppiert sein. Typedeffed Namen haben oft "_t" an ihren Namen angehängt.
Vermeiden Sie Namen, mit denen Konflikte auftreten könnten verschiedene Standardbibliotheksnamen. Etwas Systeme enthalten mehr Bibliothekscode als du willst. Auch Ihr Programm darf eines Tages verlängert werden.
Nach dies Stack Overflow Antwort , das "_t" Postfix für Typnamen ist in C reserviert. Wenn ich %code% benutze, um einen neuen Opaque Type zu erstellen, bin ich es gewohnt, eine Art Hinweis darauf zu haben, dass dies ein a ist Art. Normalerweise würde ich mit etwas wie %code% gehen, aber jetzt brauche ich etwas anderes.
Gibt es ein Standardbenennungsschema für Typen in C? In anderen Sprachen ist die Verwendung von CapsCase wie %code% üblich, aber eine Menge C-Code, den ich sehe, verwendet überhaupt keinen Großbuchstaben. CapsCase funktioniert auch ziemlich gut mit einem Bibliotheks-Präfix wie %code% .
Gibt es also eine allgemeine Regel oder einen Standard für die Benennung von Typen in C?
CapsCase wird oft für Typen in C verwendet.
Wenn Sie sich beispielsweise Projekte im GNOME-Ökosystem ansehen (GTK +, GDK, GLib, GObject, Clutter usw.), sehen Sie Typen wie %code% oder %code% . Sie nur verwenden CapsCase für Datentypen; Funktionsnamen und Variablen sind alle Kleinbuchstaben mit Unterstrichtrennzeichen - z. %code% .
Typennamensschemata sind wie Einrückungskonventionen - sie erzeugen religiöse Kriege mit Menschen, die für ihren bevorzugten Ansatz eine Art moralische Überlegenheit behaupten. Es ist sicherlich besser, dem Stil im vorhandenen Code oder in verwandten Projekten zu folgen (z. B. für mich, GNOME in den letzten Jahren).
Wenn Sie jedoch bei Null beginnen und keine Vorlage haben, gibt es keine feste Regel. Wenn Sie daran interessiert sind, effizient zu programmieren und die Arbeit zu einer vernünftigen Zeit zu verlassen, so dass Sie nach Hause gehen und ein Bier oder was auch immer trinken können, sollten Sie sich einen Stil aussuchen und bei Ihrem Projekt bleiben, aber es spielt keine Rolle, welchen Stil Sie wählen .
Eine alternative Lösung, die ziemlich gut funktioniert, ist die Verwendung von Großbuchstaben für alle Typnamen und Makronamen. Globale Variablen können CapCase (CamelBack) und alle lokalen Variablen Kleinbuchstaben sein.
Diese Technik hilft, die Lesbarkeit zu verbessern, und nutzt auch die Sprachsyntax, die die Anzahl der Verschmutzungszeichen in Variablennamen reduziert; z.B. gvar, kvar, type_t usw. Zum Beispiel können Datentypen nicht syntaktisch mit irgendeinem anderen Typ verwechselt werden.
Globale Variablen lassen sich leicht von Einheimischen unterscheiden, wenn Sie mindestens einen Großbuchstaben haben.
Ich stimme zu, dass vorangestellte oder nachgestellte Unterstriche in allen Token-Namen vermieden werden sollten.
Sehen wir uns das Beispiel unten an.
Es ist klar, dass InvertedCount aufgrund seines Falles global ist. Es ist ebenso klar, dass INT32U und RET_ERR aufgrund ihres Sytaxtyps sind. Es ist auch klar, dass INVERT_VAL () ein Makro ist, weil es auf der rechten Seite steht und es keine Umwandlung gibt, also kann es kein Datentyp sein.
Eins ist jedoch sicher. Unabhängig davon, welche Methode Sie verwenden, sollte sie mit dem Kodierungsstandard Ihrer Organisation in Einklang stehen. Für mich, die geringste Menge an Krempel, desto besser.
Natürlich ist Stil ein anderes Thema.
%Vor%Es gibt viele Ideen und Meinungen zu diesem Thema, aber es gibt keinen universellen Standard für die Benennung von Typen. Das Wichtigste ist, konsequent zu sein. In Ermangelung von Codierungsstandards, bei der Pflege von Code, widerstehen Sie dem Drang, eine andere Namenskonvention zu verwenden. Die Einführung einer neuen Namenskonvention kann, selbst wenn sie perfekt ist, unnötige Komplexität hinzufügen.
Das ist eigentlich ein großartiges Thema, wenn man Leute interviewt. Ich bin nie auf einen guten Programmierer gestoßen, der dazu keine Meinung hatte. Keine Meinung oder keine Leidenschaft in der Antwort zeigt an, dass die Person kein erfahrener Programmierer ist.
C reserviert nur einige Verwendungen eines %code% Suffixes. Soweit ich das beurteilen kann, sind dies nur aktuelle Bezeichner, die mit %code% und einem Bezeichner enden, der %code% oder %code% (7.26.8) startet. POSIX reserviert jedoch möglicherweise mehr.
Es ist ein allgemeines Problem in C, da Sie extrem flache Namespaces haben, und es gibt keine Wunderwaffe. Wenn Sie mit CapCase-Namen vertraut sind und diese für Sie gut funktionieren, sollten Sie sie weiterhin verwenden. Andernfalls müssen Sie die Ziele des aktuellen Projekts bewerten und herausfinden, welche Lösung am besten zutrifft sie.
Eine alternative Lösung, die ziemlich gut funktioniert, ist die Verwendung von Großbuchstaben für alle Typnamen und Makronamen. Globale Variablen können CapCase (CamelBack) und alle lokalen Variablen Kleinbuchstaben sein.
Diese Technik hilft, die Lesbarkeit zu verbessern, und nutzt auch die Sprachsyntax, die die Anzahl der Verschmutzungszeichen in Variablennamen reduziert; z.B. gvar, kvar, type_t usw. Zum Beispiel können Datentypen nicht syntaktisch mit irgendeinem anderen Typ verwechselt werden.
Globale Variablen lassen sich leicht von Einheimischen unterscheiden, wenn Sie mindestens einen Großbuchstaben haben.
Ich stimme zu, dass vorangestellte oder nachgestellte Unterstriche in allen Token-Namen vermieden werden sollten.
Sehen wir uns das Beispiel unten an.
Es ist klar, dass InvertedCount aufgrund seines Falles global ist. Es ist ebenso klar, dass INT32U und RET_ERR aufgrund ihres Sytaxtyps sind. Es ist auch klar, dass INVERT_VAL () ein Makro ist, weil es auf der rechten Seite steht und es keine Umwandlung gibt, also kann es kein Datentyp sein.
Eins ist jedoch sicher. Unabhängig davon, welche Methode Sie verwenden, sollte sie mit dem Kodierungsstandard Ihrer Organisation in Einklang stehen. Für mich, die geringste Menge an Krempel, desto besser.
Natürlich ist Stil ein anderes Thema.
%Vor%Es gibt viele Ideen und Meinungen zu diesem Thema, aber es gibt keinen universellen Standard für die Benennung von Typen. Das Wichtigste ist, konsequent zu sein. In Ermangelung von Codierungsstandards, bei der Pflege von Code, widerstehen Sie dem Drang, eine andere Namenskonvention zu verwenden. Die Einführung einer neuen Namenskonvention kann, selbst wenn sie perfekt ist, unnötige Komplexität hinzufügen.
Das ist eigentlich ein großartiges Thema, wenn man Leute interviewt. Ich bin nie auf einen guten Programmierer gestoßen, der dazu keine Meinung hatte. Keine Meinung oder keine Leidenschaft in der Antwort zeigt an, dass die Person kein erfahrener Programmierer ist.
Tags und Links c naming-conventions