language-agnostic - 大文字と小文字だけが型と異なる変数名を使用することは不道徳でしょうか?

Question

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

var person = new Person();

または Pythonistas の場合:

person = Person()

私はこれがどれほど悪いことかを常に言われていますが、これらの 2 行のコードが不道徳であるという例をまだ見たことがありません。私にとって、人は人であり、別の名前を付けようとするのは時間の無駄です。シンタックスハイライトが登場する前であれば、これは大変なことだったと思います。しかし最近では、型名と変数名を区別するのは非常に簡単です。一体、ここSOで違いを見るのは簡単です.

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

score 94 · Accepted Answer

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

fastPerson
slowPerson

そうでなければちょうど

person

私は大丈夫です。

score 69 · Accepted Answer

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

Person と person の 2 つのタイプがある場合、それは非常に間違っています。

score 45 · Accepted Answer

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

Person person = new Person(); // okay

int Int = 42; // pure evil

score 18 · Accepted Answer

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

var abc = new Person();

score 15 · Accepted Answer

Person がコンテキスト内の一般的な Person である場合、「person」は非常に適切な名前です。もちろん、Person がコード内で特定の役割を持っている場合は、その役割を使用して名前を付けたほうがよいでしょう。

score 9 · Accepted Answer

そんなこと言ったら評価下がると思うけど…

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

score 8 · Accepted Answer

必ずしも「悪い」とは思いませんが、明らかに、それがどのような人であるかなど、より多くのコンテキストを与えるためにそれを修飾できれば（おそらく多くの可能性のある人のうちの1人だけを扱っています）、他の誰かがそれを選んでいますアップの方が分かりやすいかもしれません。

score 6 · Accepted Answer

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

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

誰かが反対の確固たる議論をしない限り、私は確かにこれを続けます.

score 6 · Accepted Answer

それが悪いと考えられる理由は、将来 2 Person が必要になった場合、次のようなコードになってしまう可能性があるためです。

人 person = new Person();

人物 person2 = new Person();

それは「悪い」の境界になります。ただし、その場合は、元の人物をリファクタリングして、2 つを区別する必要があります。

あなたの例では、変数名「person」はオブジェクト「Person」の完全にわかりやすい名前です。したがって、それには何の問題もありません。

score 3 · Accepted Answer

変数が 2 匹の犬を飼っている人物を表している場合は、と呼びますpersonWith2Dogs。変数のスコープが短い場合 (ループ変数のように)、人は問題ありません。

score 3 · Accepted Answer

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

score 3 · Accepted Answer

不道徳ではありませんが、グローバル検索では大文字と小文字の区別を有効にしない場合Personと両方が見つかります。personグローバル検索/置換を簡単にするためにプレフィックスを好みますが、ハンガリー語や長い/複雑なものは絶対に避けてください。だから、私は使用します...

Personクラス/型 aPerson用ローカル変数 thePerson用メソッドパラメータ myPerson用インスタンス変数 ourPerson用クラス変数用

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

score 3 · Accepted Answer

場合によります。

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

そのようなスタイルを持っていない場合は、簡単に混同され、大文字と小文字だけが異なる 2 つの名前があります。良くないね。

score 2 · Accepted Answer

あなたのしていることはいいことだと思います。一般的に、コーディング標準に合意することは重要だと思います。

たとえば、インスタンス、変数には 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 を使用する必要があります。

キャメルケース名に大文字の略語 (主に頭字語と頭字語) を含めるための単一の規則はありません。アプローチには、省略形全体を大文字のままにする (「useHTTPConnection」など) と、最初の文字だけを大文字のままにする (「useHttpConnection」など) などがあります。

キャメルケースは、コンピューティングにおいて決して普遍的なものではありません。いくつかの最新のプログラミング言語、特に Lisp および Forth ファミリーのユーザーは、ほぼ常にハイフンを使用しています。場合によっては、ほとんどのキーボードで移動する必要がないこと、単語を区切った方が読みやすいこと、大文字と小文字を区別しない言語や大文字と小文字を折り畳む言語 (たとえば、 Common Lisp は、技術的には大文字と小文字を区別する言語ですが、デフォルトで識別子を大文字に正規化 (折り畳み) します)。

score 2 · Accepted Answer

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

score 2 · Accepted Answer

この種のメソッド名は無害であるだけでなく、高品質のコードの指標になり得るというより強い主張をすることは可能です。

コードの粒度が適切であることの指標: メソッドが短く、単一目的で、わかりやすい名前である場合、変数名に多くの情報は必要ありません。多くのことを行う長いメソッドがあり、多くのコンテキストと状態を追跡する必要がある場合は、変数名をよりわかりやすいものにする必要があります。
汎用計算が汎用メソッドにプッシュダウンされていることの指標: ビジネスメソッドでデータ構造の中間操作を行う場合 (たとえば、ユーザーの配列を重複排除する必要がある場合)、変数をスコープに含める必要があります。users[]やなどの名前が付いていますdeduplicatedUsers[]。重複排除をユーティリティメソッドに移動する場合は、メソッドを呼び出すUtils.dedup(array)ことができ、重複排除されたアレイdeduplicatedArrayまたは単にresult.
Java 逆コンパイラは、ローカル変数の命名にこのようなスキームを使用することが多く (インスタンス変数とクラス変数は通常、バイトコードで使用できますが、ローカル変数は使用できません)、結果は予想よりも読みやすく、実際には多くの場合、元のソース。
Larry Wall の "Local Ambiguity is OK" の原則 ( http://www.wall.org/~larry/natural.html ) を参照してください。

score 2 · Accepted Answer

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

person を変数名として使用することが許可されていない場合は、'a' プレフィックスを追加することを検討してください。

aPerson = Person()

score 2 · Accepted Answer

オブジェクトを作成するときは、おそらく特定の用途を念頭に置いていると思います。タイプだけがその用途を反映することはめったにありません。

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

Personまた、名前が設定されていないオブジェクトの動作を確認するためにコードの単体テストを行っている場合は、それらを呼び出しunnamedPersonたり、同様のものを呼び出したりすることができます。

それを呼び出すとperson、コードを自己文書化する大きなチャンスが失われます。

score 1 · Accepted Answer

私はそれが決して不道徳ではないと言うでしょう-それは本当にあなたのベースライン変数名です。より良い名前が思いつかない場合は、その型にちなんで名前を付けるのが適切なデフォルトです（複雑な型の場合のみ-組み込み型の場合は悪です）そして、多くの場合、より良い名前はありません。変数について他に何も知らない。この方法のように

void SaveToDatabase(Person person) {...}

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

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

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

これより

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

ただし、お願いします。タイプ名の前に「a」または「t」を付けないでください。「人」の場合はIEaPerson、「人」の場合はtPerson。その非常に複雑で、価値があるとしてもあまり追加されません。さらに、インテリセンスの値を最小化できるaまたはtで始まる一連の変数でスコープを汚染し始めます。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

私に表明されたことは、コーディング基準を満たしていないことを除いて、他の誰かが私のコードを読んでいるときに混乱を加えることを避けることです。個人的には、意味がはっきりしていれば問題ないと思います。

CLR型（int、stringなど）については、Stringまたはstring（など）のいずれかを使用して型を宣言できるため、次のようなものは使用しないでください。

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

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

Decimal _decimal = item.BaseCost + item.Tax;

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

score 1 · Accepted Answer

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

大文字と小文字のみが異なる場合、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# でも同じことを行うので、一方から他方への変換は簡単です。また、大文字と小文字のみが異なる単語は読み間違えたり、実際にタイプミスしたりしやすいため、エラーが発生しにくくなります。

score 1 · Accepted Answer

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

昨日は結局なんでだろうと思ったけど

private enum DataType {NEW, OLD}

C#では動かない...

特に、C# で , , , ,... を自由にString使用stringできるDouble方法を見てください。double

score 1 · Accepted Answer

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

score 1 · Accepted Answer

Person person = new Person()

私の本では大丈夫です。

それが恐ろしいのは、あなたが持っているときです：

string Person;
string person;

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

score 1 · Accepted Answer

私もそうしていますが、なぜそれが「不道徳」であるべきなのか理解できません。時々混乱するかもしれないことは理解できますが、今日ではインテリセンスと構文の強調表示を備えた IDE があり、(間違いを犯してクラスではなく変数を参照した場合、またはその逆の場合)、あなたのエラーを非常に速く見てください。また、コンパイラもあります。:)

score 0 · Accepted Answer

それは大丈夫であるだけでなく、合理的です。

Microsoftは、プロパティにタイプと同じ名前を付けることを同様に提案しています（これは一部の人にとっては驚きかもしれません）。これは同じことではないことは知っていますが、それはあなたの思考を開くかもしれません。

http://msdn.microsoft.com/en-us/library/fzcth91k(VS.71).aspx

score 0 · Accepted Answer

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

Person aPerson = new Person();

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

score 0 · Accepted Answer

いいえ、別の名前を付けるのは悪くありません。

Person clerk = new Person();
Person manager = new Person();

悪いのは、以下のような無意味な名前を作ることです:

Person xyz = new Person();

score 0 · Accepted Answer

他の人が指摘した注意事項 (便宜上ここに要約します) を条件として、まったく問題はありません: プリミティブ型を使用しない、後で別のインスタンスが追加された場合に元のインスタンスをリファクタリングする、クラス名を区別するために char-case を使用しないなど。

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

人 person = new Person();

従業員 employee = person.getRole(EMPLOYEE);

親parent = person.getRole(PARENT);

person.getFullName();

従業員.getSalary();

親.getChildren();

parent.getFullName(); // 再生中のデコレータパターンを想定

if (person.hasRole(EMPLOYEE)) {

...

}

などなど。

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

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

score -3 · Accepted Answer

不道徳...いいえ。リファクタリングが必要以上に難しい..はい。

「_person」を試してください

language-agnostic - 大文字と小文字だけが型と異なる変数名を使用することは不道徳でしょうか?

33 に答える 33

Related

Reference