命名規則：camelCase対underscore_case？それについてどう思いますか？[閉まっている]

私は約2年間underscore_caseを使用してきましたが、最近新しいジョブのためにcamelCaseに切り替えました（後のジョブを約2か月使用しており、underscore_caseは多くのプログラマーが関与する大規模プロジェクトに適していると思いますが、主にコードが読みやすいためです）。

現在、職場の全員がキャメルケースを使用しています（コードがよりエレガントに見えるためです）。

camelCaseまたはunderscore_caseについてどう思いますか

ps私の悪い英語を許してください

編集

最初にいくつかの更新：

• 使用されているプラ​​ットフォームはPHPです（ただし、厳密なPHPプラットフォーム関連の回答は期待していませんが、誰が使用するのが最善であるかについての考えを共有することができます、それが私が最初にここに来た理由です）

• 私はキャメルケースをチームの他のエブリバディと同じように使用します（ほとんどの人が推奨するように）

• キャメルケースも推奨するZend Frameworkを使用します

いくつかの例（PHPに関連）：

• Codeigniterフレームワークはunderscore_caseを推奨しており、正直なところコードは読みやすいです。

• ZFはcamelCaseを推奨しており、ZFコードをフォローするのが少し難しいと思うのは私だけではありません。

だから私の質問は言い換えられます：

プラットフォームにFooがあり、命名規則が推奨されておらず、チームリーダーが選択する場合を考えてみましょう。あなたはそのチームリーダーです。なぜcamelCaseを選ぶのですか、それともunderscore_caseを選ぶのですか？

ps今までのところ、迅速な回答をありがとう

使用している言語にある程度依存することに同意します。シンボル名が言語の組み込みおよびストックライブラリと同じフォーマット設定に従っている場合、コードは見栄えがよくなる傾向があります。

ただし、選択肢がある場合は、ラクダの場合よりもアンダースコアの方が好きです。1つの簡単な理由から、このスタイルは読みやすいと思います。例は次のとおりです。読みやすいのはどれですか。この：

aRatherLongSymbolName

またはこれ：

a_rather_long_symbol_name

アンダースコア版の方がずっと読みやすいと思います。私の脳は、それは境界が逆の場合、他のグリフに似てグリフ、または数字（の間で、特に場合は、キャメルケースでは大文字/小文字の境界を検出することができるよりもはるかに簡単にアンダースコアを無視することができI/l、O/0、t/I、など）。たとえば、次のブール変数には、Iglooが適切な計画権限で構築されているかどうかを示す値が格納されます（間違いなくすべての一般的なユースケース）。

isIllicitIgloo

私は、このバージョンは見つけるたくさん読みやすく：

is_illicit_igloo

おそらく、読みにくいシンボル名よりもさらに悪いのは、読みやすいシンボル名です。適切なシンボル名は自己文書化されます。つまり、私にとっては、シンボル名を一目で読んでその意味を理解できるはずです。（私たちは皆、喜びのためにベッドでコードの印刷物を読んでいると確信していますが、時折急いで歩き回ることもあります。）ラクダケースシンボル名を使用すると、誤読しやすく、間違った印象を受けることがよくあります。シンボルのセマンティクス。

プラットフォームで採用されている命名規則を使用すべきだと思います。underscore_caseは、C＃コードでは奇妙に見えます（RubyのcamelCase =）

正直なところ、チームの全員が同じスキームを使用している限り、それは実際には重要ではありません。どちらかはあなたにとってより自然なことかもしれませんが、本当の重要性は長い目で見たコードの可読性であり、誰もが同じ命名規則に従うことが重要です。

ジョン・アイザックスの返信に基づいて：

「正直なところ、コードは読みやすい」意見や事実？

私はいくつかの調査を行うことにし、この論文を見つけました。科学はこのテーマについて何を言わなければなりませんか？

1. キャメルケーシングは、アンダースコアよりも正確である可能性が高くなります。（オッズは51.5％高い）
2. 平均して、ラクダの場合は0.42秒長くなり、13.5％長くなります。
3. トレーニングは、スタイルが正確さにどのように影響するかに統計的に有意な影響を与えません。
4. それらより多くのトレーニングが迅速だったキャメルケーススタイルで識別子に。
5. 1つのスタイルでのトレーニングは、他のスタイルの検索時間に悪影響を及ぼします。

このテーマに関するブログ投稿で、科学論文をレビューし、次の結論を出しました。

ラクダケース の遅さ（2）のみがプログラミングに実際に関連しており、他のポイントは、最新のIDEと調査の大部分のcamelCaseユーザーのために無関係であるとして却下されています。議論（および投票）は、ブログの投稿で見つけることができます。

この記事がどのように意見を変えるか興味があります。:)

Smartest Guysをコピーする

プログラミング言語の場合、言語の開発者のスタイルをコピーします。

たとえば、K＆Rで行われているようにCを正確にコーディングします。

そして、誰かが退屈なコーディングスタイルの会話を始めようとすると、「デニスリッチと一緒に育てて、彼の言うことを教えてください」と伝えることができます。

一般的に、私はcamelCaseを好みます。しかし、それは私のキャリアのほとんどが、スタイルガイドが通常camelCaseを推奨する言語と環境で働いているためです。（Java、ECMAScript、C ++）。あなたは、PHPの人間であるため、逆の好みを持つ可能性があります。

つまり、threeOrFourWordsを超える場合、またはXmlForExampleのような初期化を使用する場合、読みにくくなります。

そのため、emacsはメガネモードを提供します。

キャメルケース

これは、読みやすさよりも常に「タイプ能力」を選択する数少ない場所の1つです。CamelCaseは入力しやすいだけで、指に優しい方が読みやすさが向上します。

もちろん、プロジェクトが異なる標準の既存のコードベース上に構築されないと仮定します。

これは興味深い質問です。これについて何度も考えてきました。しかし、明確な答えはありません。

「文化的な」慣習に従って、それは良い選択です。この場合の「文化的」とは、チーム/会社で設定された規則を意味し、基本的に言語/プラットフォームの規則も保持します。他の人があなたのコードを簡単に読んだり使用したりするのに役立ち、あなたのコードを理解する方法に入るための追加の努力と時間を必要としません。

時々、受け入れられている表記法を破ることは興味深いです。私の小さなプロジェクト（Python）の1つは、underscored_namesユーティリティ関数/「保護された」メソッドに使用し、メソッドにはJavaスタイルmethodNamesを使用しました。私のチームはそれに満足していました:)

プログラミング言語に依存します。

ハンガリー表記を使用するかどうかの同じボートでケースを使用することを検討します。

• Python：underscore_case、ハンガリー語表記なし
• C ++：ラクダケース、ハンガリー記法

両方！

私はCakePHPで多くの開発を行っており、次のように（CakePHPプロジェクト以外でも）CamelCaseまたはを使用$underscored_varsしています。

1. ファイル名 — /lowercased_underscored.php典型的ですが、言及する価値があります。
2. クラス — class CamelCase extends ParentObject。を使用するCamelCase場合、最初の文字は小文字ではないことに注意してください。私は本当に奇妙camelCaseに見えます。
3. 変数 —$are_variables_underscored === TRUE;
4. インスタンスを保持する変数 -$CamelCase = new CamelCase();
5. 配列キー —$collection['underscored_keys'];
6. 定数 —定数が必要であることは誰もが同意できると思いますALL_CAPS_AND_UNDERSCORED。
7. メソッド —$CamelCase->foo_method_underscored();
8. 静的メソッド —CamelCase::just_like_regular_methods();

個人的にはunderscore_case読みやすいと思いますが、既存のコードベースとの整合性がはるかに重要であると指摘する他の回答者に同意します。

しかし、「あなたの言語とそのライブラリの慣習に従う」と言う人には反例があります。

以前は、WindowsでCコードを記述しunderscore_case、PascalCaseWin32関数を使用して呼び出しました。

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

関数名とMicrosoftの関数名の視覚的な区別は、コードが「システムランド」に入ったときに明確に示されたように、障害ではなく助けになりました。

さらに、エディターの構文強調ルールを変更して、異なる色で表示することができました。これにより、コードのなじみのないセクション（または自分のセクション）を理解しようとすると、さらに視覚的な手がかりが得られました。

私はディランのちょうど普通のダッシュが好きで、タイプしやすく読みやすいのが大好きです。

好む

result-code := write-buffer(file-stream, some-string)

しかし、この言語はかなりあいまいであるため、これは一種のオフトピックです... :(

私は大学でラクダケースを使うように教えられました。私はここ数年でいくつかの異なる規則を使用しましたが、他の何よりもラクダケースを好みます。ラクダケースは実際に読んで理解するのが一番簡単だとどこかで読んだことを覚えていると思います。

ほとんどの人が言っているように-既存の標準を使用します。新しいプロジェクトの場合は、使用する言語とフレームワークの標準を使用してください。

混乱しないでください。これは読みやすさ（主観的）の問題ではなく、一貫性と専門性の問題です。多数の「標準」が進行しているコードベースで作業した人なら誰でも理解できます。

時々ミックスを使用します：module_FunctionName。モジュール内のすべての（非静的）関数は、モジュールの略語で始まります。

たとえば、I2Cバスでバッファのコンテンツを送信する関数：

i2c_BufferSend()

代替案でi2c_buffer_sendは、接頭辞と関数名の間に十分な大きな隔たりがありません。i2cBufferSendプレフィックスの混在が多すぎる（このモジュールにはかなりの数のI2C関数があります）。

i2c_Buffer_send しかし、代替手段だったかもしれません。

私の答えは、プロジェクトに最適なもの（言語、SWアーキテクチャなど）に適応するということであり、これらのスタイルを混在させることが役立つ可能性があることを指摘したかったのです。

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase。I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why。

個人的には、camelCaseが好きですが、一部のフォントでは、アンダースコアの方が読みやすいと思います。

変数のセットを区別するためにプレフィックスを使用する必要がある場合は、ネームスペースやオブジェクト、またはその情報を保持する何かを作成できる言語を使用することをお勧めします。

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

同様に、タイプを区別する必要がある場合、それらを許可する言語を使用してみませんか？

var intThingy = 7; // :(

int thingy = 7;    // :)

そのストレートを取得し、名前をメタデータとして使用しているだけではない場合、その余分なキーを押すかどうかに関係なく、それは非常に重要なほど長い名前を持ちません。

最初は、dafmetalに同意します。異なるプログラミングスタイルを混在させないことが最も重要です。同じファイルでこれを行うことは、私見でできる最悪のことです。異なるファイル間では、注意をそらしますが、致命的ではありません。

次にやらなければならないことは、あなたが書いている言語で人気のある命名規則です。インスタンス用の私のC ++コードは、明らかにPythonのものとは異なって見えます（PEP8はここでの良いガイドです）

また、おそらく定数にUPPER_CASEを使用するのと同様に（これはもちろん特定の言語にのみ適用されます）、ローカル変数名にはthis_styleを使用できますが、インスタンス/メンバーにはcamelCaseを使用できます変数。これは、selfまたはそういったものがある場合には必要ないかもしれませんthis。

更新

プラットフォームFoo witchが命名規則を推奨しておらず、それを選択するのがチームリーダーの選択である場合を考えてみましょう。あなたはそのチームリーダーであり、なぜcamelCaseを選ぶのか、なぜunderscore_caseを選ぶのですか。

本当に他の上の1つの利点はありません。この問題は非常に主観的であり、一度合意されると、違いは生じません。これらの小さなものについては、これらの宗教的な戦争が常にあります。しかし、どちらかに慣れると、議論はまったく不要になります。

非常によく似た問題についてAlex Martelliを引用するには：

確かに、Rubyでは、各ブロックの最後に愚かな「終了」を入力するのにうんざりします（単にインデントを解除するのではなく）-しかし、Pythonが必要とする均等に愚かな「：」の入力を避けることができます各ブロックの 開始点であるため、ほとんどウォッシュです:-)。「@foo」と「self.foo」などの構文の違い、またはRubyとPythonの大文字と小文字の重要性は、私とはまったく無関係です。

他の人は間違いなくそのような問題に基づいてプログラミング言語を選択し、最もホットな議論を生み出しますが、私にとっては、これはパーキンソンの法則の1つの例にすぎません（問題の議論の量は問題の量に反比例します実際の重要性）。

ソース

あなたがチームリーダーである場合、あなたは1人で行きます。1つは他のどれよりも有利ではないため、サイコロを投げるか、より好きなものを選ぶことができます。

数年前に、第一言語として英語を話さないプログラマーは、そのラクダのケースを理解しやすいようにアンダースコアのケースを見つける傾向があることを読みましたが、参照を見つけることができません。

Java、Python、C ++などの使用したプログラミング言語では、明確な形式を採用しました。

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

これにより、私が扱っているものをすぐに識別できます。私は自分自身を維持するのに役立つことを発見しました。コードを読んでいる他の人が簡単にフォローできるはずです。他の人が述べたように、一貫性が最も重要だと思います。そのため、名前の種類を明確に区別しながら、維持するのに十分なシンプルな形式であることがわかりました。interface_Names_Are_Like_ThisとAbstract_Classes_Are_Like_Thisは拡張の可能性があると想像できますが、従うのはより複雑で、区別するのに有用ではないようです。

HTMLパーサーをHTMLParserやHTMLparserの代わりにHtmlParserのように厳密に指定し、PascalCaseで名前を付けることも便利だと感じました。厳密なルールを覚えやすく、単語の境界を明確に保つ方が簡単だと思うからです（残念ながら、HTMLやSQLなどのつづりの間違いが必要です）。同様にcamelCaseでは、HTMLParserMethodまたはHTMLparserMethodの代わりにhtmlParserMethod。

更新：

それ以来、これらのルールを拡張してプライベート変数を含めることに用途を見出しました。-_private_variable_names_are_prefixed_with_an_underscore-_PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Javaでは、これはプライベートフィールドがローカル変数とは異なるネームスペースに定義されていることを意味しますthis.。つまり、プライベートフィールドをスキップできます。「m」という接頭辞を付けた他の形式もありますが、これらの形式では変数名にcamelCaseも使用されます。これはまた、唯一のクラスによって内部的にアクセスする必要があるフィールド間の区別をし（そしてそれは作るために私を可能にする、スーパー、それはクラスの外で起こったときに明らかobject._field_xに際立っ）。

それが私の場合、プログラマーとしてシンボルIfItIsInCamelCaseまたはin_underscore_spaceまたはin_SomeOtherStyleを読み取り、その意味を理解できるので、特定のスタイルの使用を強制または示唆しません。シンボルの解析に少しの時間を費やさなければならないことは、大きなスキームの大きなオーバーヘッドではありません。

今、私が推測する規則の主な議論は、関数/変数名の形式が何であるかを事前に知っていて、それを調べる必要がないことです-それはLoadXMLFile、loadXMLFile、LoadXmlFile、load_xml_fileですか？ここで、「インテリセンススタイルの自動補完をサポートするIDEを入手してください！」（ただし、常に可能とは限りません）。

ただし、コンパイラ/インタープリターが実際に気にしないため、最終的には、どのスタイルを使用するかは重要ではありません。重要なのは、名前が有用であることです：

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

3つの異なるスタイルがありますが、それぞれが何をするかを正確に知っています。

ばかげているように見えるかもしれませんが、アンダースコアは薄く、複数行のテキストに隠れているため、アンダースコアが好きではありません。また、一部の（多くの）テキストエディターや開発環境では、トークン名をダブルクリックしてコピーまたはドラッグアンドドロップするためにトークン名をダブルクリックすると、システムはトークン全体を強調表示せず、一部のみを強調表示しますトークンの、隣接するアンダースコアの間。それは私を夢中にさせます。

私はEclipseでの私の開発のほとんどを行う愚かな理由（Javaの場合、PHPとJavaScript）のためのキャメルケースを好む傾向にある、と私は時にCtrl+ ←またはCtrl+ →言葉で、それは実際にキャメルケースの境界で停止します。

すなわち：myIntVariableとき3つの単語としてのEclipseによって処理されるだろうCtrl+ ← →それをINGの」。

私はそれが奇妙な癖であることを知っていますが、私はラクダケースの名前の中の単語を編集できることを好みます。