命名規則：camelCaseとunderscore_case？それについてどう思いますか？
私は約2年間underscore_caseを使用してきましたが、新しいジョブのために最近camelCaseに切り替えました（後のジョブを約2か月間使用していましたが、underscore_caseは、多くのプログラマーが関与する大規模プロジェクトに適していると思いますが、主にコードが読みやすいためです）。
今では、コードはよりエレガントに見えるため、職場の誰もがcamelCaseを使用しています。
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
私はこのバージョンをlot読みやすいと思います：
is_illicit_igloo
おそらく、読みにくいシンボル名よりもさらに悪いのは、読みにくいシンボル名です。良いシンボル名は自己文書化されています。つまり、私にとっては、それらを読んでその意味を一目で理解できるはずです。 （私たちは皆、喜んでベッドでコードの印刷物を読んでいると確信していますが、急いでたまに読むこともあります。）キャメルケースのシンボル名をよく読んで、間違って読んだり、シンボルのセマンティクス。
プラットフォームで採用されている命名規則を使用する必要があると思います。 Ruby =）のcamelCaseのように、underscore_caseはC＃コードでは奇妙に見えます
正直なところ、チームの全員が同じスキームを使用している限り、それは本当に問題ではありません。どちらかといえば自然に可能性は高いですが、本当の重要性は長期的にはコードの可読性であり、すべての人が同じ命名規則に従うことが重要です。
返信に基づいて、ジョン・アイザックスの返信：
「正直なところ、コードは読みやすい」意見または事実？
私はいくつかの調査を行うことに決めました、そして この論文 を見つけました。科学はこの問題について何を言わなければなりませんか？
- ラクダのケーシングは、アンダースコアよりも正確さの確率が高い。 （オッズは51.5％高い）
- 平均して、ラクダの場合は0.42秒長く、13.5％長くなりました。
- トレーニングは、スタイルが正確さにどのように影響するかに統計的に有意な影響を与えません。
- キャメルケーススタイルの識別子では、トレーニングが多い方が迅速でした。
- 1つのスタイルのトレーニングは、他のスタイルの検索時間に悪影響を及ぼします。
私のブログ投稿 について、私は科学論文をレビューし、次の結論を出します。
キャメルケースの遅延（2）のみがプログラミングに本当に関連し、他の点は無視します最新のIDEと研究のキャメルケースユーザーの大多数のために無関係です。ディスカッション（および投票）はブログ投稿にあります。
この記事がどのように意見を変えるか興味があります。 :)
賢い人をコピー
プログラミング言語の場合は、その言語の開発者のスタイルをコピーしてください。
たとえば、K＆Rで行われるのとまったく同じようにCをコーディングします。
次に、誰かが退屈なコーディングスタイルの会話を開始しようとするときに、「デニスリッチに持ち込んで、彼の言っていることを知らせて」と伝えることができます。
一般的に、私はキャメルケースを好みます。しかし、それは私のキャリアのほとんどが、スタイルガイドが通常camelCaseを推奨する言語と環境で働いているためです。 （Java、ECMAScript、C++）。 PHP人であるあなたは、反対の好みを持っている可能性があります。
そうは言っても、threeOrFourWordsを超える場合、またはXmlForExampleのような初期化を使用する場合は、読みにくくなります。
これが、emacsがメガネモードを提供する理由です。
camelCase
これは、読みやすさよりも常に「タイプ能力」を選択する数少ない場所の1つです。 CamelCaseの方が入力が簡単で、指に優しい方が読みやすさが少し向上します。
もちろん、プロジェクトが異なる標準の既存のコードベースに基づいて構築されていないと仮定します。
興味深い質問です。これについて何度も考えました。しかし、明確な答えはないと思います。
「文化的」な慣習に従って、それは良い選択です。この場合の「文化的」とは、チーム/会社で設定された規則を意味し、基本的には言語/プラットフォームの規則も保持します。他の人があなたのコードを簡単に読んだり使ったりするのを助け、あなたのコードを理解するために追加の努力と時間を必要としません。
時々、受け入れられた表記法を破ることは興味深いです。私の小さなプロジェクトの1つ（Python上）を使用しましたunderscored_namesはユーティリティ関数/「保護された」メソッド、JavaスタイルのmethodNamesはメソッドです。私のチームはそれに満足していました:)
プログラミング言語によって異なります。
ハンガリー語表記を使用するかどうかの同じボートでケースを使用することを検討します。
- Python：underscore_case、ハンガリー語表記なし
- C++：camelCase、ハンガリー語表記
どちらも！
私はCakePHPで多くの開発を行っており、CamelCaseまたは_$underscored_vars_のいずれかを次のように使用しています（CakePHPプロジェクト以外でも）。
- filenames — _
/lowercased_underscored.php_一般的ですが、言及する価値があります。 - クラス — _
class CamelCase extends ParentObject_。CamelCaseを使用する場合、最初の文字は小文字ではないことに注意してください。私はcamelCaseを見つけて本当に奇妙に見ます。 - 変数 — _
$are_variables_underscored === TRUE;_ - インスタンスを保持する変数 —
$CamelCase = new CamelCase(); - 配列キー — _
$collection['underscored_keys'];_ - constants —定数は_
ALL_CAPS_AND_UNDERSCORED_でなければならないことに誰もが同意できると思います。 - メソッド —
$CamelCase->foo_method_underscored(); - 静的メソッド —
CamelCase::just_like_regular_methods();
個人的にはunderscore_caseの方が読みやすいと思うので好んでいますが、既存のコードベースとの一貫性がはるかに重要であると指摘する他の回答者に同意します。
しかし、「あなたの言語とその図書館の慣習に従ってください」と言う人たちの反例があります。
以前は、Windowsでunderscore_caseを使用してCコードを記述し、PascalCase Win32関数を呼び出していました。
if (one_of_our_conditions_is_true())
{
call_one_of_our_functions();
CallSystemFunction();
}
関数名とMicrosoftの関数名の視覚的な違いは、コードが「システムランド」に入った時期を明確に示しているので、妨げではなく助けでした。
さらに、エディターの構文強調表示ルールを変更して、それらを異なる色で表示することができました。これにより、見慣れないコードのセクション（または私自身のセクション）を理解しようとするときに、さらに視覚的な手がかりが得られました。
私はディランのちょうど普通のダッシュが好きで、タイプが簡単で、読みやすい。
お気に入り
result-code := write-buffer(file-stream, some-string)
しかし、この言語はかなりあいまいなので、これは一種の話題外です... :(
大学でキャメルケースを使うように教えられました。私は過去数年間にいくつかの異なる規則を使用しましたが、何よりもcamelCaseを好みます。 camelCaseが実際に最も読みやすく理解しやすい場所で読んだことを覚えています。
個人的にはキャメルケースが好きですが、一部のフォントではアンダースコアの方が読みやすいと思います。
変数のセットを区別するために接頭辞を使用する必要がある場合は、名前空間やオブジェクトなどを作成してその情報を保持できる言語を使用することをお勧めします。
myName = 7
bobsName = 8 // :(
me.name = 7
bob.name = 8 // :D
同様に、タイプを区別する必要がある場合は、タイプを許可する言語を使用してみませんか？
var intThingy = 7; // :(
int thingy = 7; // :)
名前をそのまま使用し、名前をメタデータとして使用するだけではない場合、追加のキーを押すかどうかに関係なく、非常に重要な長い名前はありません。
ほとんどの人が述べたように-既存の標準を使用します。新しいプロジェクトの場合は、使用する言語とフレームワークの標準を使用してください。
混乱しないでください。これは読みやすさ（主観的なもの）ではなく、一貫性があり、プロフェッショナルであることです。多くの「標準」が進行中のコードベースで作業したことがある人なら誰でも理解できるでしょう。
私は時々ミックスを使用します：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。
私が使用したプログラミング言語（Java、Python、C++など）では、明確な形式を採用しました。
- ClassNamesArePascalCase
- methodNamesAreCamalCase
- variable_names_are_underscore
- CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES
これにより、自分が何を扱っているかをすぐに見分けることができます。私はそれを自分で維持するのに役立つことがわかりました。また、コードを読んでいる他の人が簡単にフォローできるはずです。他の人が述べたように一貫性が最も重要だと思います。したがって、名前のタイプを明確に区別しながら、維持するのに十分簡単な形式であることがわかりました。私はinterface_Names_Are_Like_ThisとAbstract_Classes_Are_Like_Thisを拡張の可能性として想像できますが、理解するのがより複雑になり、区別するのにあまり役に立たないようです。
HTMLParserやHTMLparserの代わりにHtmlParserとしてHTMLパーサーを使用するなど、PascalCaseで厳密で名前を付けると便利です。厳密なルールを覚えておく方が簡単で、Wordの境界がより明確に保たれると思います（残念ながら、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を使用しています。これにより、クラスによって内部的にのみアクセスされるフィールドを区別することもできます（そして、クラスの外部で発生している場合はsuperを明確にしますobject._field_xが目立ちます）。
最初、dafmetalに同意します。異なるプログラミングスタイルを混在させないことが最も重要です。これを1つの同じファイルで行うと、IMHOを実行できる最悪の事態になります。さまざまなファイルにわたって、それは気が散りますが、致命的ではありません。
あなたがしなければならない次のことは、あなたが書いている言語で人気のある命名規則です。インスタンス化のための私のC++コードは、Pythonの場合とは明らかに異なります（PEP8はここに素敵なガイド）
また、おそらく定数にUPPER_CASEを使用する限り（これは特定の言語にのみ適用されます）、異なる名前付け規則を使用して別のものを参照することもできます。ローカル変数名にはthis_styleを使用できますが、インスタンス/メンバーにはcamelCaseを使用します。変数。ただし、selfやthisのようなものがある場合、これは必要ない場合があります。
更新
Foo witchが命名規則を推奨しないプラットフォームがあり、チームリーダーがそれを選択する場合を考えてみましょう。あなたはそのチームリーダーです。なぜcamelCaseを選ぶのか、なぜunderscore_caseなのか。
実際、どちらか一方の利点はありません。この問題は非常に主観的であり、いったん合意されると、違いは生じません。これらの小さなことについては常にこれらの宗教的な戦争があります。しかし、どちらか一方に慣れると、議論は完全に不要になったようです。
非常によく似た問題についてAlex Martelliを引用すると、次のようになります。
確かに、Rubyでは、各ブロックの終わりに（単にインデントを解除するのではなく）愚かな "end"を入力することにうんざりしています-しかし、次にPythonは、各ブロックのstartに必要なので、ほとんど洗浄です:-)。 '@foo'と 'self.foo'のような他の構文の違い、またはRubyとPythonの大文字と小文字の違いの重要性）は、私にとってはほとんど同じです。
他の人は間違いなくプログラミング言語の選択をそのような問題だけに基づいており、最もホットな議論を生み出しています-しかし私にとってそれは実際のパーキンソンの法則の1つの例にすぎません（議論の量問題の実際の重要性に反比例します）。
あなたがチームリーダーである場合、あなたは1人で行くだけです。 1つは他よりも利点がないため、サイコロを投げるか、好きなものを選ぶだけです。
私が数年前に読んだのは、第一言語として英語を話さないプログラマーは、アンダースコアのケースを見つけるとキャメルのケースを理解しやすくなるということですが、リファレンスを見つけることができません。
プログラマーとしては、シンボルとしてItItIsInCamelCaseや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は、Eclipseによって3ワードとして扱われます。 Ctrl+← →それを通り抜ける。
私はそれが奇妙な癖であることを知っていますが、私はキャメルケース名の中間の単語を編集できることを好みます。
ばかげているように見えるかもしれませんが、アンダースコアは細く、複数行のテキストに隠れて見逃すため、アンダースコアは好きではありません。また、一部の（多くの）テキストエディターや開発環境では、トークン名をダブルクリックして強調表示してコピーまたはドラッグアンドドロップすると、システムはトークン全体を強調表示せず、一部のみを強調表示しますトークンの、隣接するアンダースコアの間。それは私を狂わせる。