関数パラメーター名の前にp *を付ける利点は何ですか？

関数パラメーターの前にを付けたプロジェクト（Eclipseを使用するJavaプロジェクトおよびチーム）をよく見ますp。

例えば

public void filter (Result pResult) ...

私は個人的にはこれには何の利点も見ていませんが、その理由は何か知りたいです。私が聞いた中で最も良い説明は、同じ名前のフィールドの名前を区別することだということです。その説明には問題がありますが、ポイントは理解できます。

よく知られているハンガリー表記法など、シンボルに意味のある接頭辞を追加する方法は、IDEが存在しなかったり、あまりにも原始的だった時代にさかのぼります。今日、マウスのクリックだけで宣言のポイントを見つけるとき、共通のプレフィックスを割り当てることによって、名前の最初の数文字の最も貴重な部分を台無しにすることは意味がありません。

ご想像のとおり、パラメーター名とメンバーまたはローカル変数名の名前の衝突を避けるためです。メンバー変数には、同じ理由で接頭辞が付けられる場合があります（例：）m_result。個人的にはthis、名前の衝突がある場合は、メンバー変数にプレフィックスを使用することを好みます。言語に組み込まれており、誰もがその意味をすでに知っています。

パラメーターがコンストラクターやセッターなどのメンバー変数に割り当てられることを意図している場合にのみ、パラメータープレフィックスを使用します。

Paint (newColor) {
  color = newColor;
}

私にとっては、「this」プレフィックスを使用するよりも、異なる変数名を使用する方が目がくらむほど明白です。

他の状況では、メンバー変数と簡単に混同される可能性のあるパラメーターの使用を避けます。

メソッドまたはクラスが非常に大きく、変数の意味がわかりにくい場合、実際の解決策は、それをより小さなメソッド/クラスに分割することです。プレフィックスの使用は、根本的な問題に対処するバンドエイドソリューションです。

各メソッドパラメータ名の接頭辞として「p」を使用する標準を作成すると、メソッド本体の残りの部分でメソッドパラメータを簡単に認識できます。

メソッドパラメータを見つける時間を節約できます。コードを簡単にデバッグできます。

ショート-この方法により、コードが読みにくくなります。

長い-私はそれが他の悪い習慣をサポートするためだけに使用される悪い習慣であると主張します。そのようなプレフィックスを使用することが役立つと考えられるいくつかの理由を調べてみましょう。

• 変数名の衝突を避ける

  • パラメーター名はパラメーターが何であるかを正確に表していますか？「まったく同じ」パラメーターとクラスフィールドがある場合、パラメーターは必要ありません。
  • この場合、Aaronの答えで説明したnew *プレフィックスのようなクラスコンストラクターのプレフィックスを使用するだけです。また、セッターメソッドにも役立つ場合があります。

  public void setHeight(int newHeight) { this.height = newHeight; }

• メソッドは多くのパラメータを取り、多くの変数を宣言しますが、どれがパラメータであるかを簡単に忘れることができます。

  • 前述のように、問題は変数の数にあります。
  • プログラムはおそらくうまく構成されていません。すべての変数が「独立」しているかどうかを確認します-おそらく、それらは構造またはクラスに編成される必要があります。このような数の変数を操作するために、計算またはプロセス全体を別のクラスにラップする必要があるかもしれません。
  • このような数の変数が必要な場合でも、意味のある名前を使用する必要があり、接頭辞はユーザーと意味のある部分の間にあります。
• メソッドは非常に長く、プレフィックスを使用してパラメータとは何かを追跡する必要があります。
  • 問題はメソッドの長さにあります-プログラムが適切に記述されている場合、常にメソッドヘッダーとその全体が1つの画面に表示されるはずです。
  • メソッドを小さなブロックに分割してみてください。

特定の場合を除いて、パラメータプレフィックスを追加しても症状の解決に役立つだけで、実際の問題は解決しません。

私は、入力用のiParamと出力用のoParamのファンです。私は変更のためにcParamと言いますが、それは受け入れられません