型だけが大文字と小文字で異なる変数名を使用するのは不道徳ですか？

たとえば、次のコードを見てください。

var person = new Person();

またはあなたのためにPythonistas：

person = Person()

私は常にこれがいかに悪いかと聞かれますが、これらの2行のコードの不道徳の例をまだ見ていません。私にとって、人は人であり、それに別の名前を付けようとすることは時間の無駄です。構文強調表示の前の数日間は、これは大きな問題だったと思います。しかし最近では、型名と変数名を区別するのは非常に簡単です。ここで、SOの違いを確認するのも簡単です。

それとも私が見逃しているものはありますか？もしそうなら、問題を引き起こすコードの例を提供できると助かります。

これが悪いとあなたが言っている理由は何ですか？私はいつもこれをします。これは、型の単一の変数に名前を付ける最も簡単で表現力豊かな方法です。2つのPersonオブジェクトが必要な場合は、次のpersonような意味のある形容詞を前に付けることができます。

fastPerson
slowPerson

そうでなければ単に

person

私は大丈夫です。

このパターンはメソッドシグネチャでよく使用されます。私が代替の説明的な名前を提供できない場合、私見は、これには何の問題もありません。

間違っているのは、人と人の2つのタイプがある場合、それは非常に悪いことです。

私は一時的なオブジェクト参照のためにいつもそれを使用しています。プリミティブデータ型のペストのようにそれを避けます。

Person person = new Person(); // okay

int Int = 42; // pure evil

誰かがそれが悪だと言ったら、これが良いかどうか尋ねてください：

var abc = new Person();

Personがコンテキスト内の一般的なPersonである場合、「person」は本当に良い名前です。もちろん、Personがコードで特定の役割を持っている場合は、その役割を使用して名前を付けることをお勧めします。

そう言って反対投票になると思いますが...

壮大な殺人と貪欲を目の当たりにして1世紀を経た今、私たちができる最も不道徳なことは変数に名前を付けることであれば、プログラマーは本当に祝福されています。

私はそれが必ずしも「悪い」とは思いませんが、明らかに、それがどのような人物であるかなど、より多くのコンテキストを与えるためにそれを修飾できる場合（あなたはおそらく多くの可能な人物のうちの1つだけを扱っています）、それから誰かがそれを選びます良く理解するかもしれません。

ジェイソン-これが悪いと誰が言ったのかわかりません。多くの作成者は、これをクラス（大文字）のインスタンス（小文字）を表現する標準的な方法として使用しています。

小文字の変数が、これがインスタンスであるだけでなく、クラスの名前でもあることを実際に伝えているので、私はこれをよく使用します。

反対の意見がある場合を除き、私は確かにこれを続けます。

それが悪いと考えられている理由は、もしあなたが将来2人の人を持つ必要があるなら、あなたはそのようなコードで終わることになるでしょう。

Person person = new Person（）;

Person person2 = new Person（）;

それはそれから「悪い」に隣接しているでしょう。ただし、その場合は、元の人物をリファクタリングして、両者を区別する必要があります。

たとえば、変数名「person」は、オブジェクト「Person」を完全に説明する名前です。したがって、何の問題もありません。

それが何であるかという名前を言います。変数が2匹の犬を持つ人を表す場合、それをと呼びますpersonWith2Dogs。変数のスコープが（ループ変数のように）短い場合、人は問題ありません。

私はコードでそれを多く使用しており、問題はないと思います。そうは言っても、私は（おそらく）1つの画面よりも長く、Personクラスのインスタンスが複数ある場合は、メソッドでそれを使用しません。person1、person2、person3などの名前は絶対に付けないでください。代わりに、person_to_del、person_to_ban、person_to_updateなど、よりわかりやすい名前を使用してください。

不道徳ではないが、グローバル検索は両方を見つけるだろうPersonし、personあなたがアクティブ大文字と小文字の区別に失敗した場合。私は、グローバルな検索/置換を容易にするために接頭辞を好みますが、ハンガリー語や長い/複雑なものは絶対に避けてください。だから、私は...

Personクラス変数のインスタンス変数の メソッドパラメータの aPersonローカル変数 のクラス/タイプ thePersonmyPersonourPerson

まれに、p大量の参照があるローカルコンテキストで使用することがありますが、これは通常、ループインデックスなどにのみ適用されます。

場合によります。

厳密な大文字のスタイルがあり、変数が小文字で始まり（単語の区切りにunder_scoresまたはcamelCaseを使用）、クラスが大文字で始まる場合、personは変数であり、Personはクラスであり、誰かがこれを理解すると、それらは名前空間が重複しているようには見えません。（同様に、人々は動詞または名詞「polish」と形容詞「Polish」の間で混乱することはほとんどありません。）

そのようなスタイルがない場合は、混乱しやすい2つの名前があり、大文字と小文字のみが異なります。それは良くないね。

それらの人々が使用する正確な議論は何ですか？

変数名としてpersonを使用できない場合は、「a」プレフィックスを追加することを検討してください。

aPerson = Person()

あなたがやっていることは大丈夫だと思います。一般に、コーディング標準に同意することが重要だと思います。

たとえば、インスタンス、変数にはlowerCamelCaseを使用し、クラスなどにはUpperCamelCaseを使用します

コーディング標準はこの問題を取り除くはずです。

成功したオープンソースプログラムを見ると、コーディング標準がよくある

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

コーディング標準に同意することは、これに対する最後の戦いになるはずです。

実際、ウィキペディアのエントリを見てください（http://en.wikipedia.org/wiki/CamelCaseから）

プログラミングとコーディングのスタイル

ソースコードを記述するためのコーディングスタイルガイドライン（Mesaプログラミング言語やJavaプログラミング言語など）で単語の境界を示すために、内部の大文字化が推奨される場合があります。これらのガイドラインの一部に含まれる推奨事項は、ソースコードの準拠をチェックする静的分析ツールによってサポートされています。

これらの推奨事項は、UpperCamelCaseとlowerCamelCaseを区別することが多く、通常、特定の種類のエンティティ（変数、レコードフィールド、メソッド、プロシージャ、タイプなど）に使用する種類を指定しています。

広く使用されているJavaコーディングスタイルの1つでは、UpperCamelCaseをクラスに使用し、lowerCamelCaseをインスタンスとメソッドに使用することが規定されています。[19] この使用法を認識して、Eclipseなどの一部のIDEは、CamelCaseに基づくショートカットを実装しています。たとえば、Eclipseのコンテンツアシスト機能では、キャメルケースの単語の大文字だけを入力すると、一致するクラスまたはメソッド名が提案されます（たとえば、「NPE」と入力してコンテンツアシストをアクティブにすると、「NullPointerException」が提案されます）。

プログラミングのための元のハンガリー語表記では、「使用法タイプ」（データ型ではない）の小文字の省略形は、すべての変数名の前に、UpperCamelCaseの残りの名前を付ける必要があります。そのため、lowerCamelCaseの形式です。CamelCaseは、Javaのファイル名およびAmigaパーソナルコンピュータの公式の規則です。

Microsoft .NETでは、パラメーターおよび非パブリックフィールドにはlowerCamelCaseを、その他の種類の識別子にはUpperCamelCase（別名 "Pascalスタイル"）を推奨しています。[20]

Pythonでは、クラス名にUpperCamelCaseを推奨しています。[21]

NIEMレジストリでは、XMLデータ要素がUpperCamelCaseを使用し、XML属性がlowerCamelCaseを使用する必要があります。

CamelCase名に大文字の略語（主に頭字語と頭文字）を含めるための単一の規則はありません。アプローチには、省略形全体を大文字（「useHTTPConnection」など）のままにして、最初の文字のみを大文字（「useHttpConnection」など）のままにすることが含まれます。

キャメルケースは、コンピューティングでは決して普遍的ではありません。いくつかの最新のプログラミング言語のユーザー、特にLispおよびForthファミリーのユーザーは、ほとんど常にハイフンを使用します。時々与えられる理由の中には、そうすることはほとんどのキーボードでシフトを必要としないこと、それらが分離されたときに単語がより読みやすくなること、そしてキャメルケースが大文字小文字を区別しないまたは大文字小文字変換言語（例えばCommon Lispは、技術的には大文字と小文字を区別する言語ですが、識別子をデフォルトで大文字に正規化（折りたたみ）します）。

その種類のメソッド名は無害であるだけでなく、良質のコードの指標にもなり得るというより強力な議論をすることは可能です。

• 優れたコード粒度の指標：メソッドが短く、単一目的で、わかりやすい名前が付けられている場合、変数名に多くの情報は必要ありません。多くのことを行う長いメソッドがあり、多くのコンテキストと状態を追跡する必要がある場合は、変数名をよりわかりやすくする必要があります。

• 汎用メソッドにプッシュダウンされている汎用計算のインジケーター：ビジネスメソッドでデータ構造の中間操作を行う場合、たとえば、ユーザーの配列を重複排除する必要がある場合は、スコープ内に変数が必要です。users[]およびのような名前でdeduplicatedUsers[]。あなたは、ユーティリティメソッドに重複排除を移動する場合は、メソッドを呼び出すことができUtils.dedup(array)、あなたは、重複排除の配列を呼び出すことができるdeduplicatedArrayかだけresult。

• Javaデコンパイラーは、ローカル変数の名前付けにこのようなスキームを使用することが多く（インスタンス変数とクラス変数は通常バイトコードで使用できますが、ローカル変数は使用できません）、結果は予想よりも読みやすく、実際には多くの場合より読みやすくなっています元のソース。

• ラリーウォールの「ローカルあいまいさは大丈夫」の原則を参照してください-http ://www.wall.org/~larry/natural.html 。

オブジェクトを作成するときはいつでも特定の用途があると思います。タイプだけでは、その使用をほとんど反映しません。

したがって、アドレス帳アプリケーションで新しい連絡先を作成する場合は、変数を呼び出しますnewContact。

また、コードをユニットテストPersonして、名前が設定されていないオブジェクトの動作を確認している場合は、それらunnamedPersonまたは類似のものを呼び出すことができます。

それを呼び出すことpersonは、コードを自己文書化する大きなチャンスを単純に忘れてしまいます。

VB6でプログラミングしている場合のみ。その場合、あなたがしていることは違法ですが、不道徳ではありません。

私もそれをします、そしてそれがなぜ「不道徳」でなければならないのか私も理解しません。私はそれが時々混乱するかもしれないことを理解できますが、今日私たちはインテリセンスと構文の強調表示を備えたIDEを持っています。エラーをすばやく確認してください。また、コンパイラもあります。:)

また、この方法で問題が発生することはありません。そのクラスの変数が1つだけである限り、書き込みと読み取りは簡単です。Imo、それは基本的なテキストエディタにも当てはまります。私は個人的に、これを悪いまたは不道徳とさえ呼んでいる人を思い出すことはできません。これを続けてください:)

あなたが考えているかもしれない「ルール」は、プリミティブ型、およびクラス名が不適切な変数名を作成するクラスを対象としていると思います。

たとえば、オンラインストアで特定のアイテムのコストを計算する場合、次のコードは適切な形式ではありません。

Decimal _decimal = item.BaseCost + item.Tax;

代わりに、 '_total'や '_cost'など、よりわかりやすい名前をお勧めします。

この種の問題で私が見つけた唯一の問題は、プライベートメンバーとパブリックプロパティに同じ名前が必要かどうかです。

これらが大文字と小文字のみで異なる場合、C＃などの大文字と小文字を区別する言語では問題なく機能しますが、VB.NETでは機能しません。

たとえば、VBでは、次のように記述します

Private _name As String

だが

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

同じことをC＃でも行うので、一方から他方への変換は簡単です。また、読み間違えや、大文字と小文字のみが異なるタイプミスの単語が非常に発生しやすいため、エラーが発生しにくくなります。

不道徳ではありませんが、変数の最高の名前が型の名前である場合、何かがおかしいか、単に概念実証などを行っています。私にとって変数名は、プログラミング言語ではなく、ビジネスコンテキストでの意味を参照する必要があります。コードを理解するのはより難しくなります。

私はよくPerson person = new Person()自分を使います。一般的にJava / C＃で使用されます。

なぜか昨日気になってしまいましたが

private enum DataType {NEW, OLD}

C＃では動作しません...

特に、あなたがどのように使用できるかを見てString、string、Double、double、...意志でC＃で。

Person person = new Person()

私の本では大丈夫です。

恐ろしいのは、次の場合です。

string Person;
string person;

2を混ぜるのは非常に簡単です。

他の誰かが私のコードを読んでいるときに混乱を招くのを回避することで、コーディング基準を満たしていないことを除いて、私に表現されました。個人的には、意味がはっきりしている限り問題ありません。

CLRタイプ（int、stringなど）については、Stringまたはstring（など）を使用してタイプを宣言できるため、次のようなものは使用しません。

int Int = 0;
string String = "hi there";

大文字を唯一の違いにするのは危険です...大きなプロジェクトでこれを続けてください。見つけられないように見える奇妙なエラーに遭遇することを保証します。

上記のようなfastPerson / slowPersonは問題ありません...それらは説明的であり、変数の型名とは区別されます...しかし、当然ですが、int "Int"を呼び出すのは簡単です。

私はそれが決して不道徳だと言います-それは本当にあなたのベースライン変数名だけです。より適切な名前が考えられない場合は、そのタイプに基づいて名前を付けることをお勧めします（複雑なタイプの場合のみ -組み込みタイプの場合は悪です）。多くの場合、より適切な名前がないので、変数について他に何も知らない。この方法のように

void SaveToDatabase(Person person) {...}

あなたが人を合理的に呼ぶことができる他の唯一のものについて、person_to_saveまたは冗長であると思われるもののようなものです。

ただし、多くの場合、personをよりわかりやすい名前に置き換えることにより、コードを読みやすくすることができます。たとえば、これはあまり説明的ではありません

void AddToAccount(Account account, Person person)  {...}

これより

void AddToAccount(Account account, Person dependent)  {...}

ただし、どうぞ、タイプ名の前に「a」または「t」を付けないでください。IE aPerson for 'a person'またはtPerson for 'the person'。非常に複雑であり、値を追加してもそれほど多くありません。さらに、インテリセンスの値を最小化できるaまたはtで始まる一連の変数でスコープを汚染し始めます。

恐ろしいとは思いません。私は通常、変数の名前の前に 'a'を付けて、それが型の単一のインスタンスであることを示しているので、

Person aPerson = new Person();

コードがより自然に読み取れるようになると思います。

他の人から指摘された警告の影響を受けて、絶対に問題はありません（便宜上、ここに要約します）。プリミティブ型でそれを行わない、後で別のインスタンスが追加された場合に元のインスタンスをリファクタリングする、クラス名を区別するために大文字小文字を使用しない、など。

私の経験則？コード内のステートメントは、単純な英語の文章のように読む必要があります。

Person person = new Person（）;

従業員employee = person.getRole（EMPLOYEE）;

親親= person.getRole（PARENT）;

person.getFullName（）;

employee.getSalary（）;

parent.getChildren（）;

parent.getFullName（）; //プレイ時にデコレータパターンを想定

if（person.hasRole（EMPLOYEE））{

  ...

}

などなど。

変数のスコープが制限されている場合（カプセル化の方法は10〜15行など）、「person」の代わりに「p」を使用することもできます。変数名を短くすると、コンテキストを頭の中に入れようとするときに気が散ることが少なくなります。'a'や（shudder）ハンガリー語表記などの不要な接頭辞とその派生語は避けてください。（注意してください、適切なコンテキストで使用した場合、私はそのような接頭辞に対して何もしません-C ++ / COM / ATL / Win32 APIコードなど。割り当て/型キャストをまっすぐに保つのに役立ちます）。

私の2つ（！）ビット:-)