関数パラメーターの前にp
を付けるプロジェクト(Java Eclipseを使用するプロジェクトおよびチーム内)がよく見られます。
例えば
public void filter (Result pResult) ...
私は個人的にはこれで何の利点も見ませんが、その理由が何であるか知りたいのですが。私が聞いた中で最も良い説明は、同じ名前のフィールドの名前を区別することです。その説明には問題がありますが、ポイントは理解できます。
よく知られている ハンガリー表記 などの意味のある接頭辞をシンボルに追加する方法は、IDEの時代にさかのぼります存在しないか、あまりにも原始的でした。今日、宣言のポイントを見つけるのがマウスクリックである場合、共通のプレフィックスを割り当てることによって、名前の最も貴重な部分である最初の数文字を台無しにしても意味がありません。
ご想像のとおり、これは、パラメーター名とメンバー名またはローカル変数名の間の名前の衝突を回避するためのものです。メンバー変数には、同じ理由で接頭辞が付けられる場合があります(例:m_result
)。個人的には、名前の衝突がある場合は、メンバー変数にthis
接頭辞を使用することを好みます。それは言語に組み込まれており、誰もがそれが何を意味するかをすでに知っています。
パラメーターがメンバー変数(コンストラクターやセッターなど)に割り当てられることが意図されている場合にのみ、パラメータープレフィックスを使用します。
Paint (newColor) {
color = newColor;
}
私にとっては、「this」接頭辞を使用するよりも、異なる変数名を使用する方が盲目的に明白であることがわかります。
他の状況では、メンバー変数と簡単に混同される可能性のあるパラメーターの使用を避けます。
メソッドまたはクラスが大きすぎて変数の意味がわかりにくい場合、実際の解決策は、それをより小さなメソッド/クラスに分割することです。プレフィックスの使用は、根本的な問題に対処するバンドエイドソリューションです。
各メソッドパラメータ名の接頭辞として「p」を使用するように標準化すると、メソッド本体の残りの部分でメソッドパラメータを簡単に認識できます。
メソッドのパラメーターを見つける時間を節約できます。コードを簡単にデバッグできます。
Short-この方法はコードを読みにくくします。
長い-私はそれが他の悪い習慣をサポートするためだけに使用される悪い習慣であると主張します。このような接頭辞の使用が役立つと考えられる理由をいくつか調べてみましょう。
変数名の衝突を回避する
public void setHeight(int newHeight) { this.height = newHeight; }
メソッドは多くのパラメーターを受け取り、多くの変数を宣言します。どちらがパラメーターであるかは簡単に忘れてしまいます。
一部の特定の場合を除いて、パラメータプレフィックスの追加は症状のみに役立ち、実際の問題を解決しません。
私は入力用のiParamと出力パラメータ用のoParamのファンです。変更にはcParamと言いますが、それは受け入れられません