大文字と小文字のみがタイプ名と異なるパラメーター名を使用することは、C＃では悪い習慣と見なされていますか？
クラスのプロパティと一致するパラメーター名に関して、これと同様の質問が表示されますが、C＃での大文字小文字の違いを除いて、パラメータータイプ名と同じパラメーター名の使用に関して何も見つかりません。それは私が見つけることができる違反ではないようですが、それは悪い習慣と考えられていますか？たとえば、私は次の方法を持っています
public Range PadRange(Range range) {}
このメソッドは範囲を取り、パディングが適用された新しい範囲を返します。そのため、一般的なコンテキストを考えると、パラメーターのよりわかりやすい名前は考えられません。しかし、「心理的距離」についてコードコンプリートを読んだときに覚えたヒントを思い出します。それは言う
心理的距離は、2つの項目を簡単に区別できることとして定義できます...デバッグするときは、類似の変数名間および類似のルーチン名間の心理的距離の不足によって引き起こされる問題に備えてください。コードを作成するときは、大きな違いがある名前を選択して、問題を回避できるようにします。
私のメソッドのシグネチャには多くの「範囲」が続いているため、この心理的な距離に関して問題になる可能性があります。今、私は多くの開発者が次のことをするのを見ています
public Range PadRange(Range myRange) {}
私は個人的にこの大会に強い嫌悪感を抱いています。変数名に「my」プレフィックスを追加しても、追加のコンテキストはありません。
次も見ます
public Range PadRange(Range rangeToPad) {}
これは「my」接頭辞よりも好きですが、全体的には気にしません。それは、私には過度に冗長に感じられ、変数名として読みにくくなっています。私には、メソッド名のために範囲が埋め込まれることが理解されています。
したがって、これらすべてがレイアウトされているので、私の直感は最初の署名で行くことです。私には、それはきれいです。不要なときにコンテキストを強制する必要はありません。しかし、私は自分自身または将来の開発者をこの慣習に害を及ぼしていますか？ベストプラクティスに違反していますか？
これを考えすぎないでください、Range range 結構です。私はこのような種類の命名をC＃で15年以上、おそらくC++ではるかに長く使用しており、それとはまったく逆の実際の欠点を経験したことがありません。
もちろん、同じスコープ内に同じタイプのローカル変数が複数ある場合、それらを適切に区別するためにいくつかの精神的な努力を払うことはおそらく役立つでしょう。
私はいつもこれをやっています、それは私に大きな心の安らぎを与えています。メンバーに割り当てる必要があるコンストラクターに渡される引数である場合、私のメンバーにもrangeという名前が付けられ、割り当ては次のようになります。
this.range = range;
そして、私は通常、Rangeという名前のプロパティを持っています。
それらはすべて同じものであり、コンテキストが異なるだけなので、1つの名前を維持することは理にかなっており、1つの名前だけを覚えておかなければなりません。それは一つのことです、違いは純粋に技術的なものです。
あなたは「これ」で完全に資格のあるメンバーに対して厳格であるべきです。ただし、それがStyleCopの目的です。
StyleCopサイドノート
論争は保証されました！
「これ」の使用に反対する人々に：私は_、m、m_だけを見てきました。言語自体が、クラスメンバーを扱っていることを示す完全に明確で明確な普遍的に認識可能な方法を提供しています。いったいなぜ、あなたはすでに完全な名前を切り捨てるあなた自身の方法を作りたいのですか？
それがC時代からの伝統的な習慣であると私が考えることができる唯一の理由は、他に方法がなかったのでそれを実際に行うことが理にかなっているときです。
「もっとキャラです！」マジ？ 「コンパイル時間が急増します！」マジ？ 「入力時に小指を持ち上げる必要があります！」。タイピング時間が開発時間全体に何らかの意味を持っているかのように。
あなたが慣れ親しんでいるものとは異なるあらゆるスタイルが何らかの反対を生むことを認識しています。しかし、これを一貫して使用することは議論するのが難しいです。新しいコードファイルをプッシュする前に、StyleCopを実行すると、 "this"修飾子が不足している多くのメンバーが見つかります。 「これ」入れました。クリップボードに、メンバーが実行して挿入します。全然努力なし。
StyleCopはこれ以上のことをします（笑）。開発者が後継者の保守作業を（コードのフォーマットのみを考慮して）挫折させることができる方法はたくさんあります。 StyleCopはそれらのほとんどを防ぎます。それは非常に貴重です。
初心者の場合：通常、1〜2週間はつぶやくので、気に入るはずです。
メソッド、パラメーター、変数の命名に関する私の自己指導は非常に簡単です。
- 名前に渡される、または返される型が名前に含まれている場合、それは間違っています。
- 何を意図しているのかではなく、意図しているものに名前を付けます。
- コードは書かれている以上に読み取られることを常に覚えておいてください。
したがって、私の意見では、最適なメソッドシグネチャは次のようになります。
Range Pad(Range toPad)
メソッド名を短くすることは自明です。
パラメータ名toPadは、パディングされて返されるそのパラメータがインプレースで変更される可能性があることを読者にすぐに伝えます。対照的に、rangeという名前の変数については、仮定を行うことはできません。
さらに、メソッドの実際の本体では、導入された他のRange変数はその意図によって名前が付けられる（推奨される）ため、paddedとunpaddedを使用できます。 .. toPadはこれらの命名規則に準拠していますが、rangeは突出し、ゲル化しません。
コード要素（型、変数、関数など）の命名について、自問する重要な質問は
タイプミスをした場合、コンパイラはそれを見つけてくれますか？
最悪のタイプミスに基づくバグは、コードがコンパイルされて実行されるバグですが、微妙な理由により、予想とは異なる動作を示します。そして、それはタイプミスが原因であるので、コードを検査しているとき、通常、それを確認することは非常に困難です。タイプミスによってコードのコンパイルが停止した場合、コンパイラは問題の原因となっている行にフラグを立て、簡単に見つけて修正できます。
タイプと変数が大文字でのみ異なる状況では、これが常に当てはまります。 （またはほぼ常に-十分な努力を払えば、きちんと機能させることができると確信していますが、実際に試してみる必要があります。）では、大丈夫だと思います。
心配する必要があるのは、現在のスコープにrangeおよびRangeという2つの変数、メソッド、関数、またはプロパティがあるかどうかです。その場合、コンパイラはおそらくそれを通過させ、実行時に予期しない動作をすることになります。これは、「2つの変数」や「2つの関数」だけでなく、これらのタイプのコード要素のanyの2つであることに注意してください。これらはすべて暗黙的に相互にキャストでき、その結果、それが実行されると大虐殺。警告が表示される場合がありますが、それ以上の保証はできません。 rangeおよびRangeと呼ばれる2つの型が宣言されている場合も、同様の問題があります。
また、同じことが ハンガリー語表記 スタイルにも当てはまります。ここでは、名前の前に1つまたは複数の文字を付けて、それが何であるかについて何かを述べています。たとえば、Rangeと呼ばれる変数とPRangeと呼ばれるその変数へのポインターがある場合、誤ってPを見逃してしまいがちです。 C＃はこれをキャッチする必要がありますが、CおよびC++はせいぜい警告のみを表示します。さらに心配なことに、DRangeというダブルバージョンがあり、それをFRangeというフロートバージョンにダウンサンプリングするとします。フロートを偶然に使用すると（キーボードのキーが隣接しているので簡単です）、コードは一種機能しますが、奇妙で予測できない方法でフォールオーバーしますプロセスが解像度を使い果たし、アンダーフローしたとき。
8文字、16文字、または任意の制限という名前の制限があった時代はもうありません。初心者が変数名が長いとコーディングに時間がかかると不平を言うのを時々聞いたことがある。これについて不満を言うのは初心者だけです。真面目なコーダーは、本当に時間がかかることは、あいまいなバグを見つけ出すことであることを知っています-ネーミングの悪い選択は、その特定の穴に落ちる古典的な方法です。
追加したい逸話、Range rangeこれは構文的には合法であり、デバッグまたはリファクタリングが困難になる可能性があります。 Range型の変数がたくさんあるファイルで、「range」という名前の1つの変数を探していますか？この命名の選択の結果として、後でさらに作業を行うことになる場合があります。
ただし、これは主にコンテキスト依存です。 30行のファイルである場合、私の発言は実際には機能しません。
Range range今日では、1つの理由：構文の強調表示。 最新のIDEでは通常、タイプ名とパラメーター名が異なる色で強調表示されます。また、型と変数には、簡単に混同しないようにかなりの「論理的距離」があります。
これが当てはまらない場合は、別の名前を検討するか、この構文を強調表示できるプラグイン/拡張機能を有効にしてみます。
関数が総称である場合、パラメーターが総称になるため、総称名を持つ必要があります。
あなたが言っていることではありませんが、誤解を招くように特定されているパラメーター名を持つ汎用関数を実行する関数を見てきました。お気に入り
public String removeNonDigits(String phoneNumber)
これは多くの状況で多くの文字列に適用できるように、関数名は非常に一般的に聞こえます。しかし、パラメータ名が奇妙に特定されているため、関数名が誤解を招くのではないかと思いますが、...何ですか？
ですから、Range rangeと言う代わりに、Range rangeToPadと言うこともできます。しかし、これによりどのような情報が追加されますか？もちろんパッドする範囲です。他に何でしょうか？
「my」または「m_」などの任意の接頭辞を追加すると、追加情報が読者に伝わりません。コンパイラーが変数名を型名と同じにすることを許可しない言語を使用した場合-大文字と小文字を区別するかどうかに関係なく、コンパイルするために接頭辞または接尾辞を付けることがあります。しかし、それはコンパイラを満足させるためだけです。たとえコンパイラが区別できるとしても、これにより人間の読者が区別しやすくなると主張することができます。しかし、すごい、Javaの中で、「Customer customer = new Customer（）;」のようなステートメントを10億回書いており、混乱することはありませんでした（常に少し冗長だと思っていました） VBでそれを気に入っています。 "dim customer as new Customer"と言うだけで、クラス名を2回指定する必要はありません。）
総称名に強く反対するのは、同じ関数に同じ型のインスタンスが2つ以上ある場合です。特にパラメータ。お気に入り：
public Range pad(Range range1, Range range2)
Range1とrange2の違いは何ですか？どうやって知っているはずですか？それが本当に2つの一般的で交換可能な値である場合は、
public boolean overlap(Range range1, Range range2)
範囲がオーバーラップしている場合はtrueを返し、オーバーラップしていない場合はfalseを返すことを期待しています。
しかし、それらが異なる場合は、それらがどのように異なるかを手掛かりにしてください！私は最近、地理的な場所に関するデータを保持するための「Place」クラスがあり、「p」、「place」、「place2」、「myPlace」などの名前のこのタイプの変数を持つプログラムに取り組んでいました。名前は本当にどちらがどれかを判断するのに役立ちます。