アトリビュート、メソッド、クラスを異なる言語で命名する際の好ましい規則は何ですか？

Question

命名規則は異なる言語で似ていますか？そうでない場合、違いは何ですか？

Answer 1

は、物事は多くのことを異なりますが、ここでは様々な言語の中で最も一般的に使用される命名規則の大まかな概要です：

lowercase, lowercase_with_underscores：一般的にローカル変数や関数名に使用

（典型的には、 C構文）。一般的に変更することはありません定数と変数に使用

UPPERCASE, UPPERCASE_WITH_UNDERSCORES:

。 BASICのような（古い）言語では、すべての変数名にすべての大文字を使用するための規約もあります。典型的には、関数名と変数名に使用

CamelCase, javaCamelCase:

。あるものは関数に対してのみ使用し、変数には小文字または小文字の_with_underscoresを組み合わせます。 javaCamelCaseを使用すると、通常、関数と変数の両方に使用されます。

この構文は外部APIにとっても非常に一般的です。なぜなら、これはWin32 APIとJava APIのやり方だからです。 （ライブラリが内部的に異なる規則を使用している場合でも、彼らは通常、関数名用（Java）のキャメルケースの構文でエクスポートします。）一般的に名前空間（すなわち、C）をサポートしていない言語で使用

prefix_CamelCase, prefix_lowercase, prefix_lowercase_with_underscores:

。接頭辞は、通常、関数または変数が属するライブラリまたはモジュールを示します。通常、グローバル変数とグローバル関数に予約されています。プレフィックスは大文字でも可能です。いくつかの規則では、内部関数と変数には小文字の接頭辞を、エクスポートされたものには大文字の接頭辞を使用しています。

もちろん、名前を付ける方法は他にもたくさんありますが、ほとんどの規約は上記のものの1つに基づいているか、それらのバリエーションに基づいています。

ところで、私はハンガリーの表記法を忘れていました。

Answer 2

もちろん、いくつかの共通のガイドラインがありますが、言語の構文\ designの違いによっても違いがあります。マイクロソフトからガイドライン - 規則

Naming Guidelinesに名前を付けるなど、 コーディングガイドライン.NET上 決定的ブック -

• Framework Design Guidelines：私は、次のリソースをお勧めします.NET（C＃の、VBなど）について

• General Naming Conventions - 別のMSガイドライン（C＃、C++、VB）

Answer 3

各言語には特定のスタイルがあります。少なくとも一つの。 各プロジェクトは特定のスタイルを採用しています。少なくとも、彼らはすべきです。これはあなたの言語が使用する正規のスタイルとは異なるスタイルになることがあります。おそらく、devの指導者の好みに基づいています。

どのスタイルを使用しますか？

言語が適切な標準ライブラリに含まれている場合は、そのライブラリの表記規則を採用してみてください。

あなたの言語が正式な本（Cプログラミング言語、Camel Book、Programming Rubyなど）を使用している場合は、それを使用してください。

言語設計者（C＃、Java spring to mind）は、実際には一連のガイドラインを作成することがあります。特にコミュニティがそれを採用する場合は、それらを使用してください。

あなたが複数の言語を使用する場合は柔軟に滞在し、使用している言語にお好みのコーディングスタイルを調整することを忘れない - Pythonでコーディングする際にC＃などでのコーディングに異なるスタイルを使用

Answer 4

やあ、

私が作ることができる最良の勧告の1つは、スティーブ・マッコネルのコード・コンプリート（Amazon Link）の該当するセクションを読むことです。彼はネーミングテクニックに関して優れた議論をしています。しかし、mulitwordVarName私が働いているDEVの一部を：

HTH

歓声、

ロブ

Answer 5

は、私はほとんどの命名規則は異なりますが、開発者は、例えば、私はのような変数に名前を付けることを考えますmulitword_var_nameやmultiwordvarnameやaj5g54agのようなものを使用していますか...あなたの好みによりますか？他の人が言ったように

Answer 6

年前、賢明な古いプログラマが私にHungarian notationの邪悪を教えてくれました。これは本当のレガシーシステムでした。マイクロソフトでは、Windows SDKとそれ以降のMFCのいくつかを採用しました。これはCのようなゆるい型付き言語の周りに設計され、C++のような強力な型付き言語では設計されていません。当時、私はBorlandのTurbo Pascal 1.0 for Windowsを使用してWindows 3.0をプログラミングしていましたが、後でDelphiになりました。

この時点でとにかく長い話を短く、私が働いていたチームは、単純なプレフィックスに基づいて、非常にシンプルで、ほぼすべての言語に適用される当社独自の基準を開発 -

• - 引数
• リットル - ローカル
• メートル - メンバー
• グラム - グローバル

ここに重点がスコープにある、コンパイルに依存していますあなたが気にする必要があるのは、データが存在するスコープです。リファクタリングで何かの型を変更すると、そのインスタンスをすべて検索して置き換える必要がないという点で、古いハンガリー表記よりも多くの利点があります。

ほぼ16年後、私はまだ、この練習の利用を促進し、私が開発しているほぼすべての言語にそれが適用を発見した。