Java変数とメソッド名でアンダースコアを使用する
最近でも、Java変数とメソッドでアンダースコアが表示されることがよくあります。例としては、メンバー変数（ "m_count"や "_count"など）があります。 Sunが悪いスタイルと呼びます。
定数はキャメルケースではなくすべて大文字にする必要があるため、使用する必要がある唯一の場所は定数です（「public final static int IS_OKAY = 1;」など）。ここでは、アンダースコアによりコードが読みやすくなります。
Javaでアンダースコアを使用するのは悪いスタイルだと思いますか？そうであれば（そうでない場合）、なぜですか？
現在使用しているコードがない場合は、継続することをお勧めします。コードベースで使用している場合は、それを続けます。
コーディングスタイルの最大の利点は、一貫性です。一貫性のあるものが何もない場合は、言語ベンダーの推奨事項から始めるのが適切でしょう。
sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs（）; as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable（）;
ルール：
- 編集中のコードが行うことを行う
- ＃1が当てはまらない場合は、キャメルケースを使用してください。アンダースコアは使用しません
メンバー変数がJavaまたは他の言語で悪いことを示すために_またはm_を使用するとは思わない。スニペットを見て、ローカルからすべてのメンバー変数をすばやく識別します。
また、ユーザーにインスタンス変数の先頭に「this」を付加することでこれを実現することもできますが、これは非常に厳しいものです。多くの点で、これはDRYに違反しています。これはインスタンス変数であるため、2回修飾する理由です。
私自身の個人的なスタイルは、_の代わりにm_を使用することです。その理由は、グローバル変数と静的変数もあるためです。 m _/_の利点は、変数スコープを区別することです。したがって、グローバルまたは静的に_を再利用することはできず、代わりにそれぞれg_とs_を選択します。
「悪いスタイル」は非常に主観的です。特定の規則があなたとあなたのチームのために働くなら、私はそれが悪い/良いスタイルを修飾すると思います。
あなたの質問に答えるために：私はプライベート変数をマークするために先頭のアンダースコアを使用します。私はそれを明確にし、コードをすばやくスキャンして、何が起こっているのかを知ることができます。
（名前の衝突を防ぐことを除いて、「this」はほとんど使用しません。）
変数の前に「m_」または「_」を使用すると、オブジェクト全体のメソッドでメンバー変数を簡単に見つけることができます。
副次的な利点として、「m_」または「_」を入力すると、intellsenseが最初にポップアップします;）
アンダースコアの使用が昔はスタイルが悪いと考えられていた理由があります。ランタイムコンパイラが手に負えないものであり、モニターに驚くべき320x240ピクセルの解像度が付いていた場合、_nameおよび__name。
- 私は（プライベート）インスタンス変数の先頭のアンダースコアが好きで、読みやすくて区別しやすいようです。もちろん、これはEdgeのケースで問題を引き起こす可能性があります（たとえば、パブリックインスタンス変数（一般的ではない、私は知っています）-あなたが名前を付けるそれらはおそらくあなたの命名規則を破っている：
private int _my_int; public int myInt;? _my_int? )
-私はこれの_styleが好きで、それが読みやすいと思う限り、それは価値があるよりも間違いなく多くのトラブルだと思います、それは珍しいことであり、あなたが使用しているコードベースの他のものと一致しない可能性が高いためです.
-自動コード生成（たとえば、Eclipseのgetter、setterの生成）はこれを理解できない可能性が高いため、Eclipseを手で修正するか、Eclipseで認識して十分に修正する必要があります。
最終的に、あなたは（Java）の世界の残りの部分に反することになり、そこからいらいらするでしょう。そして、以前のポスターが言及したように、コードベースの一貫性は上記の問題のすべてに勝ります。
Javaに対するSunの推奨事項への link を次に示します。これらを使用しなければならないわけではなく、それらのライブラリコードがそれらすべてに従うこともありませんが、ゼロから始めるのであれば良いスタートです。 Eclipseのようなツールには、これらの規則（または定義した他の規則）に準拠するのに役立つフォーマッターとクリーンアップツールが組み込まれています。
私にとって、「_」は入力が難しい:)
プライベート変数とパブリック変数を区別するものがあると便利ですが、一般的なコーディングでは「_」が好きではありません。私が新しいコードでそれを助けることができるなら、私はそれらの使用を避けます。
コーディングスタイルのブレンドです。考え方の1つは、プライベートメンバーにアンダースコアを付けて区別することです。
setBar( int bar)
{
_bar = bar;
}
の代わりに
setBar( int bar)
{
this.bar = bar;
}
他の人は、アンダースコアを使用して、メソッド呼び出しの終わりにスコープ外になる一時ローカル変数を示します。 （私はこれはかなり役に立たないと思います-良い方法はそれほど長くないはずです、そして宣言はそこにあります！だから私はそれが範囲外になることを知っています）編集：神はこの学校のプログラマーとメンバーのプログラマーの共同作業を禁止！地獄だ。
時々、生成されたコードは変数の前に_または__を付けます。人間がこれを行うことはないという考えなので、安全です。
（私の経験では）人々がそれを行う理由は、メンバー変数と関数パラメーターを区別するためです。 Javaでは、次のようなクラスを使用できます。
public class TestClass {
int var1;
public void func1(int var1) {
System.out.println("Which one is it?: " + var1);
}
}メンバー変数_var1またはm_var1を作成した場合、関数にあいまいさはありません。
それはaスタイルであり、私はそれを悪いとは言いません。
言語のスタイルガイドラインに違反するスタイル（正当な理由なし）はanyいため、「悪い」と思います。
間違いなく、あなたが見たコードは、アンダースコアが受け入れられる言語で働いていた誰かによって書かれたものです。
一部の人々は、新しいコーディングスタイルに適応できません...
個人的には、言語はコーディングスタイルについてrulesを作るべきではないと思います。好み、使用法、利便性、読みやすさの概念の問題です。
今、プロジェクトmustリスト全体の一貫性のためにコーディング規則を設定します。これらのルールに同意しないかもしれませんが、貢献したい（またはチームで仕事をしたい）場合は、それらに固執する必要があります。
少なくとも、EclispeのようなIDEは不可知論的であり、変数の接頭辞や接尾辞、さまざまなスタイルのブレースの配置、スペース管理などのルールを設定できます。したがって、yourガイドラインに沿ってコードを再フォーマットできます。
注：私は、C/C++からの古い習慣を維持し、メンバー変数（および静的変数の場合はs_）のJavaの接頭辞付き）、イニシャルを使用してブール値の先頭にb関数名の大文字と中括弧の整列... Java原理主義者！;-)の恐怖
おもしろいことに、それは私が働いている場所で使われている慣習です...おそらく、最初の主な開発者はMFCの世界から来ているからでしょう！ :-D
それはあなた自身のスタイルであり、悪いスタイルのコードではなく、良いスタイルのコードでもありません。