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_読み取り可能（）;

ルール：

1. 編集しているコードが行うことを実行します
2. ＃1が当てはまらない場合は、アンダースコアなしでキャメルケースを使用してください

_またはm_を使用してメンバー変数を示すことは、Javaやその他の言語では悪いことではないと思います。スニペットを見て、ローカルからすべてのメンバー変数をすばやく特定できるため、コードの可読性が向上すると思います。

これは、ユーザーにインスタンス変数の前に「this」を付けるように強制することでも実現できますが、これはやや厳格です。多くの点で、インスタンス変数であるためDRYに違反します。なぜ、2回修飾するのですか。

私自身の個人的なスタイルは、_の代わりにm_を使用することです。その理由は、グローバル変数と静的変数もあるからです。m _ / _の利点は、変数スコープを区別できることです。したがって、_をグローバルまたは静的に再利用することはできません。代わりに、それぞれg_とs_を選択します。

「悪いスタイル」は非常に主観的です。特定の慣習があなたとあなたのチームにとってうまくいくなら、それは悪い/良いスタイルを修飾すると思います。

あなたの質問に答えるには：私は先頭の下線を使用してプライベート変数をマークします。私はそれが明確であり、コードをすばやくスキャンして何が起こっているのかを知ることができます。

（ただし、名前の衝突を防ぐためを除いて、「これ」を使用することはほとんどありません。）

変数の前に「m_」または「_」を使用すると、オブジェクト全体のメソッドでメンバー変数を簡単に見つけることができます。

副次的な利点として、「m_」または「_」と入力すると、intellsenseが最初にそれらをポップアップします;）

• 私はたまたま（プライベート）インスタンス変数の先頭の下線が好きで、読みやすく区別しやすいようです。もちろん、これはエッジケース（たとえば、パブリックインスタンス変数（一般的ではない、私は知っています）-どちらの名前でも問題になる可能性がありますそれらは間違いなくあなたの命名規則を破っています：
• private int _my_int; public int myInt;? _my_int? )

-私はこれの_styleが好きで、読みやすいと思いますが、それは珍しく、使用しているコードベースの他のものと一致しない可能性が高いため、価値があるよりも間違いなく厄介だと思います。

-自動化されたコード生成（例：Eclipseの生成ゲッター、セッター）はこれを理解できない可能性が高いため、手動で修正するか、Eclipseで認識できるようにマックする必要があります。

最終的に、あなたは（java）の世界の残りの設定に反対し、そこからいくつかの迷惑をかける可能性があります。そして、以前の投稿者が述べたように、コードベースの一貫性は上記のすべての問題よりも優先されます。

昔はアンダースコアを使うのは悪いスタイルだと考えられていたのには理由があります。ランタイムコンパイラが手ごろな価格で、モニターが驚異的な320x240ピクセルの解像度で提供されていたとき_name、とを区別するのは簡単ではありませんでした__name。

プライベート変数とパブリック変数を区別するものがあると便利ですが、一般的なコーディングでは「_」は好きではありません。私が新しいコードでそれを助けることができれば、私はそれらの使用を避けます。

これは、Javaに関するSunの推奨事項へのリンクです。これらを使用する必要があるわけではなく、ライブラリコードがすべてに従う必要があるわけでもありませんが、最初から始める場合は良いスタートです。Eclipseのようなツールには、これらの規則（または定義した他の規則）に準拠するのに役立つフォーマッターとクリーンアップツールが組み込まれています。

私にとって、「_」は入力するのが難しすぎます:)

それはコーディングスタイルのブレンドです。考え方の1つは、プライベートメンバーの前にアンダースコアを付けて区別することです。

setBar( int bar)
{
   _bar = bar;
}

の代わりに

setBar( int bar)
{
   this.bar = bar;
}

他の人は、アンダースコアを使用して、メソッド呼び出しの最後にスコープ外になる一時ローカル変数を示します。（これはかなり役に立たないと思います-良い方法はそれほど長くはないはずです、そして宣​​言はそこにあります！だから私はそれが範囲外になることを知っています）編集：神はこの学校のプログラマーとmemberData学校のプログラマーが協力することを禁じています！！それは地獄でしょう。

生成されたコードの前に_または__が付く場合があります。人間がこれを行うことは決してないという考えなので、安全です。

言語独自のスタイルガイドラインに違反するスタイルは（正当な理由なしに）醜く、したがって「悪い」と思います。

あなたが見たコードは、アンダースコアが受け入れられる言語で働いていた誰かによって書かれたことは間違いありません。

新しいコーディングスタイルに適応できない人もいます...

（私の経験では）人々がそれを行う理由は、メンバー変数と関数パラメーターを区別するためです。Javaでは、次のようなクラスを持つことができます。

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

メンバー変数を_var1またはm_var1にした場合、関数にあいまいさはありません。

だからそれはスタイルであり、私はそれを悪いとは言いません。

個人的には、言語はコーディングスタイルに関するルールを作るべきではないと思います。それは、好み、使用法、利便性、読みやすさに関する概念の問題です。
ここで、プロジェクトは、リスト間で一貫性を保つために、コーディングルールを設定する必要があります。これらのルールに同意できないかもしれませんが、貢献したい（またはチームで作業したい）場合は、これらのルールに従う必要があります。

少なくとも、EclispeのようなIDEは不可知論者であり、可変の接頭辞や接尾辞、さまざまなスタイルのブレースの配置やスペース管理などのルールを設定できます。したがって、これを使用してガイドラインに沿ってコードを再フォーマットできます。

注：私はC / C ++の古い習慣を守り、Javaをメンバー変数のm_プレフィックス（静的変数の場合はs_）でコーディングし、ブール値の前にイニシャルbを付け、関数名に最初の大文字を使用し、中括弧を揃えています。 .. Javaファンダメンタリストにとっての恐怖！;-)
おかしなことに、それは私が働いている場所で使用されている規則です...おそらく主な初期開発者はMFCの世界から来ているからです！:-D

それはあなた自身のスタイルであり、悪いスタイルのコードでも、良いスタイルのコードでもありません。私たちのコードを他のコードと区別するだけです。