型名と大文字と小文字が異なるだけのパラメーター名を使用しているのは、C＃の悪い習慣と見なされていますか？

クラスのプロパティに一致するパラメーター名に関して、これに似た質問が表示されますが、C＃の大文字と小文字を除いて、パラメータータイプ名と同じパラメーター名の使用に関しては何も見つかりません。それは私が見つけることができる違反ではないようですが、それは悪い習慣と見なされますか？たとえば、次の方法があります

public Range PadRange(Range range) {}

このメソッドは範囲を取り、パディングが適用された新しい範囲を返します。したがって、一般的なコンテキストを考えると、パラメーターのよりわかりやすい名前を考えることはできません。しかし、「心理的距離」についてのCode Completeを読んだときに拾ったヒントを思い出します。それは言います

心理的距離は、2つの項目を区別できる容易さとして定義できます...デバッグするとき、類似する変数名間および類似するルーチン名間の心理的距離が不十分であることに起因する問題に備えてください。コードを作成するときに、問題を回避できるように、大きな違いのある名前を選択してください。

私のメソッドシグネチャには多くの「範囲」が続いているため、この心理的な距離に関して問題があるように感じます。今、私は多くの開発者が次のことをしているのを見ます

public Range PadRange(Range myRange) {}

私は個人的にこの大会に強い嫌悪感を持っています。変数名に「my」プレフィックスを追加しても、追加のコンテキストは提供されません。

私はまた次を見る

public Range PadRange(Range rangeToPad) {}

「私の」プレフィックスよりもこれが好きですが、それでも全体的には気にしません。私には過度に冗長で、変数名としてぎこちなく読みます。私には、メソッド名のために範囲がパディングされることが理解されています。

このようにすべてをレイアウトしたら、私の最初は最初の署名を使用することです。私には、きれいです。不要なときにコンテキストを強制する必要はありません。しかし、私は自分自身または将来の開発者にこの慣習を傷つけていますか？ベストプラクティスに違反していますか？

これを考えすぎないでください、Range range結構です。私はそのような種類の命名をC＃で15年以上、おそらくC ++ではるかに長く使用しており、実際の欠点を経験したことはまったくありません。

もちろん、すべて同じタイプの同じスコープ内に異なるローカル変数がある場合、それらを適切に区別するための精神的な努力を払うのがおそらく役立つでしょう。

私はこれを常にします、それは私に素晴らしい心を与えています。メンバーに割り当てる必要があるコンストラクターに渡される引数である場合、私のメンバーもrangeという名前になり、割り当ては次のようになります。

this.range = range;

通常、Rangeという名前のプロパティがあります。

それらはすべて同じものであり、コンテキストが異なるだけなので、単一の名前を維持することは理にかなっており、1つの名前のみを覚えておく必要があります。それは一つのことです、違いは純粋に技術的なものです。

「this」を使用して、完全に適格なメンバーを厳しくする必要があります。しかし、それがStyleCopの目的です。

StyleCopサイドノート

論争が保証されています！

「これ」の使用に反対する人々へ：私は_、m、m_を見たが、何もなかった。言語自体は、クラスメンバーを扱っていることを示す、完全に明確で明確な、普遍的に認識可能な方法を提供しています。一体なぜすでに完璧な名前を切り取る独自の方法を作りたいのでしょうか？

私がそれを考えることができる唯一の理由は、他の方法がなかったので、実際にそれを行うことが理にかなったとき、それがC時代からのレガシー習慣であるということです。

「もっとキャラクターだ！」マジ？「コンパイル時間が急上昇します！」マジ？「入力時に小指を持ち上げる必要があります！」。入力時間は、総開発時間に重要な意味を持ちます。

私はあなたが慣れているものとは異なるスタイルが何らかの反対を提起することを認識しています。しかし、これを一貫して使用することは議論が困難です。私にとっての仕組みは次のとおりです。新しいコードファイルをプッシュする前に、StyleCopを実行すると、「this」修飾子を欠いているメンバーが多数見つかります。「これ」を入れます。クリップボードで、メンバーによって実行され、挿入します。まったく努力しません。

StyleCopはこれ以上のことを行います（笑）。開発者が（コードの書式設定のみを考慮して）後継者の保守作業をいらいらさせることができる多くの方法があります。StyleCopはそれらのほとんどを防ぎます。それは非常に貴重です。

あなたがそれに慣れていない場合：それは通常、あなたが1週間または2週間不平を言うようにし、それからあなたはそれを愛するでしょう。

メソッド、パラメーター、変数の命名に関する私の自己指導は非常に簡単です。

1. 渡されたり返されたりするタイプが名前に含まれている場合、それは間違っています。
2. 物の名前ではなく、意図したもので名前を付けます。
3. コードは、書かれている以上に読まれることを常に覚えておいてください。

したがって、私の意見では、最適なメソッドシグネチャは次のようになります。

Range Pad(Range toPad)

メソッド名を短縮するのは一目瞭然です。

パラメーター名toPadは、そのパラメーターが埋め込みによって変更される可能性が高いことを読者にすぐに伝え、その後返されます。対照的に、という名前の変数については仮定できませんrange。

さらに、この方法の実際のボディに、他のRangeあなたが持っているかもしれないので、導入されている変数は、彼らの意図によって命名する（必要がある）だろうpaddedとunpadded... toPadそれらの命名規則に準拠しますが、rangeちょうど突き出しとゲル化しません。

コード要素（型、変数、関数、あらゆるもの）の命名について、自分に問うべき重要な質問は

タイプミスをした場合、コンパイラはそれを見つけてくれますか？

最悪のタイプミスのバグは、コードがコンパイルおよび実行されますが、微妙な理由により、予想とは異なる動作をするものです。そして、それはタイプミスによるものなので、通常、コードを検査しているのを見るのは非常に困難です。タイプミスによりコードのコンパイルが停止すると、コンパイラーは問題の原因となっている行にフラグを立て、簡単に見つけて修正することができます。

型と変数の大文字と小文字のみが異なる状況では、これが常に当てはまります。（またはほぼ常に-十分な努力で、あなたはそれを動作させることができると確信していますが、あなたは本当に試してみる必要があります。）だから私はあなたがそこにいると思います。

心配する必要があるのは、現在のスコープにrangeandと呼ばれる2つの変数、メソッド、関数、またはプロパティがある場合Rangeです。その場合、コンパイラは、おそらくだろう、それを通過させる、そしてあなたは、実行時に予期しない動作を取得するつもりです。これは、「2つの変数」または「2つの関数」だけでなく、これらのタイプのコード要素のうちの2つであることに注意してください。警告が表示される場合がありますが、それ以上の保証はできません。あなたは二つのタイプが呼び出さ宣言していた場合にも、同様の問題を抱えているrangeとRange。

また、ハンガリーの表記スタイルにも同じことが当てはまります。ハンガリーの表記スタイルでは、名前の前に1つ以上の文字が付けられ、それが何であるかについて何かを言います。という変数とRangeそれへのポインタが呼び出されている場合、たとえばPRangeを誤って見落としがちPです。C＃はこれをキャッチするはずですが、CとC ++はせいぜい警告のみを出します。またはもっと心配なのは、doubleバージョンが呼び出されDRange、それをfloatバージョンにダウンサンプルするとしますFRange。フロート（キーがキーボード上で隣接しているので、簡単です）事故ずつとなりますあなたのコードを使用した種類の仕事を、そのプロセスは、解像度アンダーフローが不足すると、それは奇妙で予測不可能な方法で倒れるでしょう。

8文字、16文字、または任意の任意の制限の命名制限があった時代はもうありません。変数名が長いとコーディングに時間がかかると不平を言う初心者を時々聞きました。これについて文句を言うのは初心者だけです。真面目なコーダーは、本当に時間がかかるのはあいまいなバグを見つけ出すことであることを知っています -そして、命名の悪い選択は、その特定の穴に自分自身を落とす古典的な方法です。

追加したい逸話の1つですが、Range rangeこれは構文的には合法ですが、デバッグやリファクタリングがより困難になる可能性があります。Range型の変数がたくさんあるファイルで、「range」という名前の1つの変数を探していますか？この命名の選択の結果、後でさらに作業を行うことになります。

ただし、これは主にコンテキスト依存です。それが30行のファイルである場合、私のステートメントは実際には機能しません。

私はあなたがRange range1つの理由で今日を使用できると思う：構文強調表示。最近のIDEは通常、型名とパラメーター名を異なる色で強調表示します。また、タイプと変数には、簡単に混同しないように、かなりの「論理的距離」があります。

これが当てはまらない場合は、別の名前を検討するか、この構文強調表示を行うことができるプラグイン/拡張機能を有効にしようとします。

関数がジェネリックである場合、パラメーターがジェネリックになるため、ジェネリック名を使用する必要があります。

あなたが言っていることではありませんが、誤解を招くほど具体的なパラメーター名を持つ汎用関数を実行する関数を見てきました。好む

public String removeNonDigits(String phoneNumber)

これは多くの状況で多くの文字列に適用できるように、関数名は非常に一般的に聞こえます。しかし、パラメータ名は奇妙に具体的であるため、関数名が誤解を招くのか、それとも...

確かに、Range rangeと言う代わりに、Range rangeToPadと言うことができます。しかし、これはどのような情報を追加しますか？もちろん、それはパッドする範囲です。他に何でしょうか？

「my」または「m_」などの任意のプレフィックスを追加すると、読者にゼロの追加情報が伝えられます。コンパイラが変数名を型名と同じにすることを許可しない言語を使用した場合-大文字と小文字を区別する場合としない場合-コンパイルするために、接頭辞または接尾辞を付けることがあります。しかし、それはコンパイラを満足させるためだけです。たとえコンパイラーが区別できたとしても、これは人間の読者が区別しやすくすると主張することができます。しかし、すごい、Javaで「Customer customer = new Customer（）;」のようなステートメントを書きました。10億回、私はそれを混乱させることはありませんでした。（私はいつも少し冗長だと感じていましたが、VBでは「新しい顧客として薄暗い顧客」と言うことができ、クラス名を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」などの名前のこのタイプの変数を持つプログラムに取り組んでいました。名前は、どちらがどれかを判断するのに本当に役立ちます。