FxCopは、関数、クラス、およびプロパティはMajorCamelCaseで記述し、プライベート変数はminorCamelCaseで記述する必要があると（基本的にはメモリから）考えました。
私はIRCでかなり人気のあるプロジェクトについて話していて、いくつかのコードを引用しました。もう一人の男、かなり悪名高いトロールで、ハーフオペ（ガスプ！）でもあったのは同意しなかったようです。すべてが同じケーシングに含まれている必要があり、彼はMajorCamelCase、またはunderscore_separationを非常に熱心に支持していました。
もちろん、彼はただの荒らしだったので、私は私がすでにしたようにそれをやり続けるだろうと思いました。上記のガイドラインを学ぶ前は、一貫した命名スタイルさえほとんどありませんでした。
しかし、彼は私に考えさせました-このようなものは本当に重要ですか？
将来、コードが読み取り可能であることを確認する必要があります。アプリケーションの開発を他の人に任せたい場合は、その人がそれを読んで理解する必要があることを覚えておいてください。プロジェクトへの積極的な取り組みをやめて、1 年後にプロジェクトに戻ることもあるでしょう。そして、その仕組みを理解するためにコードを注意深く読まなければならないことに驚かれることでしょう。
特定の命名スタイルは重要ではない (一貫性がある限り、好きなものを使用できます) と述べたのは Steve McConnell だったと思いますが、これは、プロジェクトに取り組んでいる全員が同意する場合にのみ適用されます。
一般に、コードの再利用を促進し、学習曲線を短縮するために、可能な限りコミュニティで受け入れられているコーディング スタイルを採用することをお勧めします。
プロジェクトの長期的な保守性 (または一貫性や可読性) を気にしない場合は、いいえ、大文字と小文字 (および一般的なコーディング規則) は実際には重要ではありません。そうでなければ、それらは重要です。これを参照してください。
プロジェクト全体で一貫している限り、特定のコーディング スタイルは (あまり) 重要ではありません。
これにより、識別子が特定の方法で命名されているかのように、読みやすさと理解が向上します。読者は、(うまくいけば) その命名スタイルが何を意味するかについて確信を持つことができます。
CamelCase v アンダースコアなどに関しては、繰り返しになりますが、コーディング規約に依存します。両方を使用する 1 つのアプローチは、関数、またはファイル スコープ/グローバル変数が使用されるモジュールを示すためにアンダースコア付きのプレフィックスを適用することConfig_Update()ですStatus_Get()。