回答
賢い人をコピー
プログラミング言語の場合、言語の開発者のスタイルをコピーします。
たとえば、K & Rで行われるのとまったく同じようにCをコーディングします。
次に、誰かが退屈なコーディングを始めようとしたときスタイルの会話では、「デニスリッチーと一緒にそれを持ち出し、彼の言うことを教えてください」と言うことができます。
コメント
回答
一般的に、私はキャメルケースを好みます。しかし、それは私のキャリアのほとんどが、スタイルガイドが通常キャメルケースを推奨する言語と環境で働いてきたためです（Java、ECMAScript、C ++）。PHPの人であるあなたは、反対の好みを持っている可能性があります。
そうは言っても、threeOrFourWordsを超えると、またはXmlForExampleのようなイニシャリズムを使用すると、読みにくくなります。
これが、emacsがメガネモードを提供する理由です。
コメント
- +1でメガネモードを発見しました！キャメルケースを使用するコードファイルでテストしたところ、すぐに見栄えが良くなることに気づきました（アセンブリキャメルケースにたくさんのラベルがあります。）
- さて、メガネモードとは何ですか？
- gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html
回答
camelCase
これは、読みやすさよりも「タイプ能力」を常に選択する数少ない場所の1つです。 CamelCaseは入力が簡単で、指に馴染むことで、読みやすさが少し向上します。
もちろん、プロジェクトが異なる標準の既存のコードベース上に構築されていないことを前提としています。
コメント
- 同意しません'コードを1回だけ記述しますが、後で複数回読み取る必要があります
回答
これは興味深い質問です。これについては、何度も考えてきました。しかし、明確な答えはないと思います。
「文化的」な慣習に従うことは、良い選択です。この場合の「文化的」とは、チーム/会社で設定された規則を意味し、基本的に言語/プラットフォームの規則も適用します。他の人があなたのコードを簡単に読んだり使用したりするのに役立ち、「あなたのコードを理解する方法に入るのに追加の努力や時間を必要としません。
受け入れられた表記法を破ることは時々興味深いです。私の小さなプロジェクトの1つ（Pythonの場合）ユーティリティ関数/「保護された」メソッドにはunderscored_namesを使用し、メソッドにはJavaスタイルのmethodNamesを使用しました。私のチームは満足していました。それを使って：）
回答
プログラミング言語によって異なります。
ケースを使用することを検討します。ハンガリー表記を使用するかどうかの同じボート：
- Python：underscore_case、ハンガリー表記なし
- C ++：camelCase、ハンガリー表記
コメント
- @Kevin Cantu：実際にはJavascriptという名前はcamelCaseではなくPascalCaseにあります…
- @Guffa：touch é！
- @Kevin Cantu：JavaScriptの場合：
XMLHttpRequest<-私はこの名前が嫌いですwi - hypotheticalReasonsToNukeRedmond.push（XMLHttpRequest）
- @Lionel：C ++はすでに型をチェックしているため、実際にはハンガリアン記法がC ++で使用されることはほとんどありません。 'これは他の何よりも歴史的な遺物です。
回答
両方！
私はCakePHPで多くの開発を行っており、CamelCaseまたは$underscored_vars、次の方法で（CakePHPプロジェクトの外部でも）：
- ファイル名 —
/lowercased_underscored.php典型的ですが、言及する価値があります。 - クラス —
class CamelCase extends ParentObject。CamelCaseを使用する場合、最初の文字は小文字ではないことに注意してください。camelCaseが本当に奇妙に見えると思います。 - 変数 —
$are_variables_underscored === TRUE; - インスタンスを保持する変数 —
$CamelCase = new CamelCase(); - 配列キー —
$collection["underscored_keys"]; - 定数 —私は思う定数は
ALL_CAPS_AND_UNDERSCOREDである必要があることに誰もが同意できます。 - メソッド —
$CamelCase->foo_method_underscored(); - 静的メソッド —
CamelCase::just_like_regular_methods();
コメント
- 最初の文字を低くして、同意する必要がありますケースは私を夢中にさせます！私は情熱を持ってキャメルケースが嫌いです。
- 名前が通常キャメルケースであるJavaでは、クラス名は実際には大文字で始まります。これは、メソッド名と区別するためです。
回答
個人的にはunderscore_case読みやすいと思いますが、既存のコードベースとの整合性がはるかに重要であると指摘する他の回答者に同意します。
ただし、「」と言う人には反例があります。言語とそのライブラリの規則に従ってください。」
これまで、Windowsでunderscore_caseを使用してCコードを記述し、 Win32関数：
if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); } 関数名とMicrosoftの関数名を視覚的に区別することは、障害ではなく助けになりました。コードが「システムランド」に入るタイミングを明確に示しました。
さらに、エディターのシンタックスハイライトルールを変更して、さまざまな色で表示できるようにしました。これにより、次のことを行う際の視覚的な手がかりがさらに得られました。コードのなじみのないセクション（または私自身のセクション）を理解します。
回答
私はディランの普通のダッシュが簡単に入力して簡単に入力できるのが本当に好きです-読む。
のように
result-code := write-buffer(file-stream, some-string) しかし、この言語はかなりあいまいなので、これは一種のトピックから外れていると思います。 .. 🙁
コメント
- アンダースコアを入力するためにShiftキーを押すのにも疲れています。
- これは通常は不可能です。変数名の場合、"-"は通常マイナスを意味するため、
回答
大学でキャメルケースの使い方を教えられました。私はここ数年、いくつかの異なる規則を使用しましたが、他の何よりもキャメルケースを好みます。キャメルケースが実際に読みやすく理解しやすい場所を読んだことを覚えていると思います。
コメント
- まあ、'どこかで読んだので簡単ではありませんが、'だったので簡単です最初に使用したもので、主にそれに慣れているためです。たとえば、i 'はunderscore_caseの方が快適です。
- i
調査が行われ、それがより良いことがわかったと読みました。
回答
ほとんどの人が言及しているように-既存の標準を使用します。「新しいプロジェクトの場合は、使用する言語とフレームワークの標準を使用します。
混乱しないでください、これは読みやすさ（主観的）ではなく、一貫性と専門性についてです。多数の「標準」が実行されているコードベースで作業したことがある人なら誰でも理解できます。
回答
私は時々ミックスを使用します。 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。
コメント
- 最後の2行は+1ですが、命名規則を組み合わせるのはお勧めしません。その他。
- 規則が明確に定義されている限り（プレフィックス+アンダースコア+ PascalCase）…
- 意味的に互いに素な名前の部分を区切るために、アンダースコアを使用するのが好きです。目的、特にどちらかの半分の共通性が重要である可能性がある場合。たとえば、ルーチン
Motor1_Start()、Motor2_Start()、Motor1_Stop()、Motor2_Stop()関係は下線なしではわかりにくいかもしれません。
回答
個人的に、私はキャメルケースが好きですが、一部のフォントでは下線が読みやすいと思います。
変数のセットを区別するためにプレフィックスを使用する必要がある場合は、名前付けを作成できる言語を使用することをお勧めしますまたはオブジェクトまたはその情報を保持するための何か。
myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 同様に、型を区別する必要がある場合は、それらを許可する言語を使用してみませんか？
var intThingy = 7; // :( int thingy = 7; // :) 名前をメタデータとして使用するだけでなく、その名前をそのまま使用すると、十分な長さの名前が得られなくなります。その余分なキー押下を好むかどうかは非常に重要です。
コメント
- camelCaseまたはunderscore_caseを使用する理由の1つは、' tを使用しないためです。オブジェクトの定義を見つけて、それが何であるかを識別する必要があります。
回答
最初は、dafmetalに同意します。最も重要なのは、異なるプログラミングスタイルを混在させないことです。これを1つの同じファイルで実行することは、私見で実行できる最悪の事態です。さまざまなファイル間で、気が散ることはありますが、致命的ではありません。
次に行う必要があるのは、記述している言語で一般的な命名規則です。インスタンス用の私のC ++コードは明らかにPythonの場合とは異なって見えます（ここではPEP8が優れたガイドです）
定数にUPPER_CASEを使用するのと同じように、さまざまな命名規則を使用してさまざまなものを参照することもできます（これは特定の場合にのみ適用されます）もちろん言語）、ローカル変数名にはthis_styleを使用できますが、インスタンス/メンバー変数にはキャメルケースを使用します。ただし、selfやthisなどがある場合は、これは必要ない場合があります。
更新
プラットフォームを使用している場合を考えてみましょう。Foowitchは命名規則を推奨せず、チームリーダーが1つを選択します。あなたはそのチームリーダーです。なぜキャメルケースを選ぶのか、なぜunderscore_caseを選ぶのでしょうか。
どちらにも利点はありません。この問題は非常に主観的であり、一度合意されると、違いはありません。これらの小さなことについては、常にこれらの宗教的な戦争があります。しかし、どちらかに慣れると、議論はまったく不要に思えます。
非常によく似た問題についてAlexMartelliを引用するには：
確かに、Rubyでは、（インデントを解除するだけでなく）各ブロックの最後に愚かな「end」を入力することにうんざりしますが、同じように愚かな「：」を入力することは避けられます。 Pythonは、各ブロックの start で必要なので、「ほとんどウォッシュ:-)」です。「@ foo」と「self.foo」などの他の構文の違い、または大文字と小文字の区別の高さRubyとPythonは、私にはまったく関係ありません。
他の人は間違いなくそのような問題に基づいてプログラミング言語を選択し、最も熱い議論を引き起こしますが、私にとってはそれは単なる実行中のパーキンソンの法則の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としてHTMLパーサーなどの名前をPascalCaseで使用すると便利であることがわかりました。 HTMLparser。厳密なルールを覚えやすく、単語の境界を明確に保つことができると私は信じているからです（残念ながら、HTMLやSQLなどのスペルミスが必要です）。同様に、キャメルケースでは、HTMLParserMethodやHTMLparserMethodの代わりにhtmlParserMethodを使用します。
UPDATE ：
それ以来、これらのルールを拡張してプライベート変数を含めることに使用されています。–_ private_variable_names_are_prefixed_with_an_underscore-_PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE
Javaでは、これは、プライベートフィールドが定義上ローカル変数とは異なる名前空間にあることを意味します。つまり、this.
」というプレフィックスが付いた他の形式もありますが、これらの形式でも変数名にキャメルケースを使用しています。これにより、内部でのみアクセスする必要があるフィールドを区別することもできます。クラスごとに（そして、クラス外で発生した場合は super クリアにするobject._field_x目立ちます。
if (...) {を実行すると1行節約できました。最近では、'より多くの画面スペースがあります-今日高解像度のGUIIDEと複数のモニターを使用して記述した場合、K & Rは異なりますセットアップ？