Cで最も一般的な命名規則は何ですか？
Cで一般的に使用される命名規則は何ですか？少なくとも2つあることを知っています。
- Lower_case_functionsを使用したGNU/linux/K＆R
- ？名前 ？ UpperCaseFoo関数を使用
私はここでのみCについて話しています。私たちのプロジェクトのほとんどは、Cを使用する小さな組み込みシステムです。
次は、次のプロジェクトで使用する予定のあるものです。
C命名規則
Struct TitleCase
Struct Members lower_case or lowerCase
Enum ETitleCase
Enum Members ALL_CAPS or lowerCase
Public functions pfx_TitleCase (pfx = two or three letter module prefix)
Private functions TitleCase
Trivial variables i,x,n,f etc...
Local variables lower_case or lowerCase
Global variables g_lowerCase or g_lower_case (searchable by g_ prefix)
ここで最も重要なことは一貫性です。そうは言っても、GTK +コーディング規約に従います。これは次のように要約できます。
- 大文字のすべてのマクロと定数：
MAX_BUFFER_SIZE、TRACKING_ID_PREFIX。 - キャメルケース内の構造体名とtypedef：
GtkWidget、TrackingOrder。 - 構造体で動作する関数：クラシックCスタイル：
gtk_widget_show()、tracking_order_process()。 - ポインター：ここで特別なものはありません：
GtkWidget *foo、TrackingOrder *bar。 - グローバル変数：グローバル変数を使用しないでください。彼らは悪です。
- そこにあるが、直接呼び出してはいけない関数、あいまいな使用法など、最初の1つ以上の下線：
_refrobnicate_data_tables()、_destroy_cache()。
「構造体ポインタ」は、それらをカバーするための命名規則句を必要とするエンティティではありません。それらはただstruct WhatEver *です。賢い「明白な」typedefに関係するポインターがあるという事実を隠さないでください。目的を果たさず、入力する時間が長くなり、宣言とアクセスのバランスが崩れます。
まず、Cにはpublic/private/virtual関数がありません。それはC++であり、異なる規則があります。通常、Cには次のものがあります。
- ALL_CAPSの定数
- 構造体または関数名の単語を区切るアンダースコア、Cでキャメルケースが表示されることはほとんどありません。
- 構造体、typedef、共用体、（共用体と構造体の）メンバー、および列挙値は、通常、最初の文字を大文字にするC++/Java/C＃/などの慣習ではなく、小文字です（ただし、 Cも。
C++はより複雑です。ここで実際のミックスを見ました。クラス名または小文字+アンダースコアのキャメルケース（私の経験ではキャメルケースがより一般的です）。構造体はめったに使用されません（通常、ライブラリで必要なため、そうでない場合はクラスを使用します）。
C＃、Java、C、C++、Objective Cのコーディングと同時に、非常にシンプルで明確な命名規則を採用して、人生を簡素化しました。
まず、最新のIDE（Eclipse、Xcodeなど）のパワーに依存します。ホバーまたはctrlのクリックにより高速な情報を取得できる可能性があります。 IDEによって単純に指定されるその他のマーカー。
次に、規則：
- すべての名前は、あなたが持っているものを説明する読みやすい文でなければなりません。 「これは私の慣習です」のように。
- 次に、文から規則を取得する4つの方法：
- THIS_IS_MY_CONVENTIONマクロの場合、enumメンバー
- ThisIsMyConventionファイル名、オブジェクト名（クラス、構造体、列挙、ユニオン...）、関数名、メソッド名、typedef
- this_is_my_conventionグローバル変数とローカル変数、
パラメータ、構造体およびユニオン要素 - thisismyconvention [オプション]非常にローカルで一時的な変数（for（）ループインデックスなど）
以上です。
それは与えます
class MyClass {
enum TheEnumeration {
FIRST_ELEMENT,
SECOND_ELEMENT,
}
int class_variable;
int MyMethod(int first_param, int second_parameter) {
int local_variable;
TheEnumeration local_enum;
for(int myindex=0, myindex<class_variable, myindex++) {
localEnum = FIRST_ELEMENT;
}
}
}
キャメルケースとアンダースコアの分離を混在させることをお勧めします（構造体メンバーに提案したように）。これは紛らわしいです。 get_lengthを持っているので、おそらくmake_subsetを持っているはずですが、実際にはmakeSubsetであることがわかります。最小限の驚きの原則を使用し、一貫性を保ちます。
CamelCaseは、構造体、typedef、enumなどの名前を入力するのに役立ちます。ただし、これですべてです。残りすべて（関数名、構造体メンバー名など）には、underscore_separationを使用します。
シンプルに保ちたいのですが、明確にしています...それで、Cで使用するものを次に示します。
- Trivial Variables：
i,n,c、etc ...（1文字のみ。1文字が明確でない場合は、ローカル変数にします） - ローカル変数：
lowerCamelCase - グローバル変数：
g_lowerCamelCase - 定数変数：
ALL_CAPS - ポインター変数：
p_をプレフィックスに追加します。グローバル変数の場合はgp_var、ローカル変数の場合はp_var、const変数の場合はp_VARです。 farポインターを使用する場合は、fp_の代わりにp_を使用します。 - 構造体：
ModuleCamelCase（モジュール=完全なモジュール名、または2〜3文字の省略形ですが、CamelCaseのままです。） - 構造体メンバー変数：
lowerCamelCase - 列挙型：
ModuleCamelCase - 列挙値：
ALL_CAPS - パブリック関数：
ModuleCamelCase - プライベート関数：
CamelCase - マクロ：
CamelCase
構造体をtypedefしますが、タグとtypedefの両方に同じ名前を使用します。このタグは、一般的に使用されるものではありません。代わりに、typedefを使用することをお勧めします。また、カプセル化のためにパブリックモジュールヘッダーでtypedefを前方宣言し、定義でtypedefされた名前を使用できるようにします。
フルstruct例：
typdef struct TheName TheName;
struct TheName{
int var;
TheName *p_link;
};
ここに（明らかに）珍しいものがあります。これはCamelCaseのモジュール名、アンダースコア、CamelCaseの関数またはファイルスコープ名です。たとえば、次のとおりです。
Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]
私は1つのことに混乱しています。新しいプロジェクトの新しい命名規則を作成する予定です。通常、会社全体またはチーム全体の命名規則が必要です。何らかの形式の命名規則を持つプロジェクトが既にある場合は、新しいプロジェクトの規則を変更しないでください。上記の慣習が既存の慣行の成文化にすぎない場合、あなたは最高です。既存のde facto標準と異なるほど、新しい標準でマインドシェアを獲得することは難しくなります。
私が追加する唯一の提案については、uint32_tとsize_tのスタイルの型の最後に_tが好きです。私にとっては非常にCっぽいのですが、ハンガリー語で「逆」だと不満を言う人もいます。
多くの場合、主にIDEがいくつかのトレンドを決定し、C++の規則も推進しています。 Cの場合：
- UNDERSCORED_UPPER_CASE（マクロ定義、定数、列挙型メンバー）
- underscored_lower_case（変数、関数）
- CamelCase（カスタムタイプ：構造体、列挙、ユニオン）
- uncappedCamelCase（oppa Javaスタイル）
- UnderScored_CamelCase（変数、名前空間の種類の下の関数）
グローバル用のハンガリー語表記は問題ありませんが、タイプ用ではありません。些細な名前であっても、少なくとも2文字を使用してください。
また、単語の順序を考慮して、自動名前補完を簡単にする必要があります。
推奨事項：ライブラリー名+モジュール名+アクション+サブジェクト
パーツが関連していない場合はスキップしますが、少なくともモジュール名とアクションを常に提示する必要があります。
例：
- 関数名：
os_task_set_prio、list_get_size、avg_get - define（ここでは通常、noactionpart）：
OS_TASK_PRIO_MAX