短い識別子は悪いですか？[閉まっている]

短い識別子は悪いですか？識別子の長さとコードの理解はどのように相関しますか？識別子の命名に関しては、他にどのような要因（コードの理解以外）を考慮する必要がありますか？

回答の質を維持するために、このテーマに関する調査が既に行われていることに注意してください！

編集

私が提供した両方のリンクが大きな識別子が有害であることを示しているとき、誰もが長さが関連しているとは思わないか、より大きな識別子を好む傾向があることに興味があります！

リンク切れ

以下のリンクはこのテーマに関する研究を指していましたが、今は壊れています。私は論文のコピーを持っていないようで、それが何であったかを思い出しません。他の誰かがそれを理解できるように、ここに残しておきます。

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

私が聞いた最高の「ルール」は、名前の長さは変数のスコープの長さに比例する必要があるということです。そのためi、ループの本文が数行の長さであればインデックスは問題ありませんが、15行より長くなる場合は、もう少し説明的なものを使用したいと思います。

各変数には意味があり、その名前はその意味の一部です。そして、非常に重要な部分です。なぜなら、読者がアルゴリズムを深く掘り下げることなく、その目的を理解するのに役立つからです。i、jインデックスとして使用されることは明らかで、短いですが非常に有益です。bntい、closeまたはcloseButton意味があります。そのため、変数名の長短は最も重要な基準ではなく、意味のあるものでなければなりません。意味は、コンテキストに強く依存します。たとえば、n10文字というコードの小さなブロックで使用され、プロパティの名前を参照するローカル文字列変数のような非常に短い名前を付けることができます（v値は別の例です）。

そのため、変数名は有益である必要があり、変数名は短くても長くてもかまいません。

長さに関係なく、変数を記述する識別子を使用します。

i、j、およびkのケースは、それ自体が偏在するため、自己記述的であり、ループインデックスであることが自動的にわかります。以下についても同じことが言えます：

foreach loop (Strings s : myString)

ただし、IDEにはコード補完ツールが用意されているため、非常に長くて説明的な識別子のマイナスの副作用のみが削除されています。

変数の目的を説明する必要がある場合は、識別子に追加の単語を追加します。

誤解を招く識別子ほど悪くはありません。識別子が1文字だけであるコードのデバッグは気にしませんが、異なる命名規則が登場するとすぐに迷惑になります。例えば、どこかで見たらstrPersonID、次にどこかで表示s_EmployeeIDされる場合、これらの両方の文字列であるかどうかと、違いがあるかどうかを判断するのは混乱します。また、変数がコピー＆ペースト（pmapIntString = new std::map<int,int>）されていて完全に間違っている場合も心配です。

私の場合は、使用する重要な変数のコードにコメントを追加し、開発ガイドラインに記載されている標準を維持しようとします。標準がない場合、コード全体で同じ命名規則を維持しようとします。

私は苦闘する...

私は常に識別子として説明的な名前を使用しますが、最近では非常に短い識別子を使用しています。

コードのコンテキストに依存すると思います。

• 複雑な関数（アルゴリズム）を記述する場合は、常に短い識別子を使用します（単一文字が最適です）
• 関数のパラメーター値を記述するときは、説明的な名前を使用します。

コードの密度にも依存すると思います。実際に名前があると、実際には読みにくくなります。

時には名前なしで完全に不可解です！

私の考えでは、それらはそれ自体悪いものではありませんが、非常に標準的でない限り有益ではありません。

ループ変数はi、j、kですは非常に標準的であるため、インデックス付きループを作成する場合に使用しない理由はありません。

非常に短い識別子を使用するもう1つの場所は、foreachループからの一時変数など、数行後にスコープから外れる一時変数を宣言するときです。他の場所で参照されない場合、コードを読んでいる人は誰でも簡単に宣言を見て、それが使用されているものに従うことができます。ただし、5行または6行以上使用する場合は、より明確な名前を付けたいと思います。

特にクラスレベルでは、有益な長さの識別子を使用しようとしていますが、変数の目的を読んで理解できる識別子が必要です。それらが長くなりすぎている場合（そして、識別子のために4つまたは5つの単語がつながれているコードを時々見ます）、私はそれをコードの匂いと見なす傾向があります-私の変数を区別するために多くのテキストが必要な場合、実際にはそれらはグループですハッシュマップまたはリストに保存する方が良いでしょうか？このデータをより正確にモデル化するために、何らかのオブジェクトを作成できますか？できない場合もありますが、非常に長い識別子は、ここで注目に値するものがあることを示しています。

ここでの他の回答には非常に同意しますが、見落とされがちな他の要因を指摘したいと思います。良い名前は、多くの場合、コードに対して慣用的な名前です。これは、言語レベル、アルゴリズムレベル、または手元のコードベースのいくつかの内部イディオムになります。ポイントは、名前はコードのドメインを知らない人にとっては何の意味も持たないかもしれないが、与えられたコンテキストでは依然として最良の名前かもしれないということです。

変数に名前を付けることは、常に一意性と包括性のバランスをとる練習です。名前の長さは、さまざまな方法で両方に関連しています。名前が長いほど一意になりやすくなります。中程度の長さの名前は、短すぎるまたは長すぎる名前よりもわかりやすい傾向があります。

非常に短い変数名は、それが理解なる履歴（例えば、ある場合にのみ有用であるi、j、およびk、インデックスのdxまたはすべての参照は、例えば、（一度に見えるようにするために十分に小さいであるスコープ軸に沿った距離のための）を、temp）。世界で最悪の変数名はのようなものですt47。（「それはどういう意味で、なぜそれと違うのt46ですか？」）命名のスタイルが主にFORTRANで出てきたのは良いことですが、これがより長い変数名への欲求が根づいているところです。

あなたの元の論文が示したように、コードをちらっと見ると微妙な内部の違いを見逃す可能性があるため、長すぎる名前も読みにくいです。（DistanceBetweenXAxisAbscissae＆の違いをDistanceBetweenYAxisAbscissaeすぐに理解するのは本当に難しいです。）

NoteToSelfが以前に指摘したように、名前の一意性の要件は、主に名前が一意でなければならないスコープに依存します。5行のループのインデックスはi; 関数から関数に渡されるアクティブなレコードのインデックスには、よりわかりやすい名前を付けた方が良いでしょう。

関数のローカル変数には、deltaX問題のないようなわかりやすい名前を付けることができます。モジュール内の静的なデルタX変数には、このdeltaXと同じモジュール内の他のdeltaXを区別する名前を付けて、長くする必要があります。そして、おそらくモジュール名を他の記述名に連結することによって、グローバルなデルタX変数を、すべてのモジュールおよび作成される可能性のある他のすべてのモジュールにわたって一意にする必要があります。これは、グローバルに関する多くの問題の1つです。便利に一意にするために、名前は読みにくくするのに十分な長さでなければなりません。

それどころか、長い識別子は短い識別子よりも悪いと思います（定数を扱っていない限り）。を使用TheVariableThatHoldsTheCapacityOfMyContainerClassすると、コードを使用するよりもエラーが発生しやすくなりますCapacity。

で、それ自体、短い識別子は悪くありません。適切な名前（短いまたは長い）を選択する目的は、コードを明確にするためです。 コードを明確にするサービスで識別子を選択することは、最小長の要件を満たすよりも重要です。 一般に、これが意味することは、少し長い意味のある名前を書くことです。

私が長年にわたって経験してきたことは、10年前または15年前よりも今日はそれほどではありません。入力できないプログラマーは、変数の命名法をめぐってあなたと格闘するプログラマーです。これらは、すべて1〜3文字の変数名を持つものです。

そのため、多くのコメンターが言ったように意味のある名前を使用し、入力することを学びます。私は、人々がどこにいるかを見るために、インタビューにタイピングテストを追加することを検討してきましたが、コンピューターが社会の大きな部分を占めるようになるにつれて、タイピングを行っていない人の数が減ってきています。

リンクする最初の論文は興味深いように見えますが、その結論は、意味のある変数名を含む「グラウンディングヒント」がコード理解に役立つという仮説の重要な証拠を見つけられなかったということです。使用された注視滞留時間は、コード理解のプロキシとして興味深いものですが、スラムダンクではありません。

私は2番目の論文がばかげていると思った。最初の問題は、それらが提供する長い名前の例が無用に長く、余分な情報を提供しないことです。変数名を長くするだけで変数名を長くするのは馬鹿げていることに全員が同意できると思います。dxではなく変数distance_between_abscissaeを命名する彼らの例は、ストローマンです。

さらに重要なことに、彼らの実験は理解ではなく単純な暗記のテストです。コンテキストなしのリストで提示された場合、変数名の欠落部分を埋める被験者の能力をテストします。はい、長い名前は記憶するのが難しいですが、コーディングするときは変数名を記憶せず、コンテキストを提供するためにそれらを使用します。長い変数を覚えるのが難しいとコードを書くのが難しくなるが、コードは書かれているよりもはるかに頻繁に読み取られるので、どのアクティビティを最適化する必要があるのでしょうか？

コードの行が読み取り可能かどうかを判断するための主な指標の1つは、その行が何をしているのかを確実に理解するために、他の行からの他のコンテキストをどれだけ読み取る必要があるかです。

「i、j、kがループ変数であることは誰でも理解できるはずです」と言うのは簡単です。そしてほとんどの場合、それは本当に明らかです。しかし、私はまだこの点について謙虚でプロフェッショナルになり、プログラミング時に間違いを犯しやすいと考えています。したがって、Grobbleの配列をループ処理する場合、ループ変数にgrobbleIndexという名前を付けます。インデックスの略語としてiを受け入れることもできます。ijとkを使用している場合、間違った配列で間違ったインデックスを使用するなどのエラーを見つけるのは難しくなります。そして、内部ループがあるとさらに悪化します。

PS。この回答を書いたとき、vimで垂直に分割された画面を持つ10インチのミニラップトップでJavaScriptをコーディングしていましたが、ループ変数にrowIndexとcolumnIndexという名前を付けるのに時間がかかりました。

一部のアプリケーションでは、短い変数では変数内のデータを説明できません。短いか長いかは関係ありません。長い変数を使用しても、コードが遅くなることはありません。確かに長い変数名を入力するのはもっと手間がかかりますが、少なくとも6か月後にコードを読んだ人（あなたかもしれません）は、それが可能であると仮定してトレースを置く必要なく、何が起こっているかを知ることができます。

私は、理想的には名前が説明的でなければならないことだと思うしない限り ...

名前が短くなる可能性があります（そうするべきである）という考え（したがって、暗示的な説明が少ない）は、名前の範囲が制限されている場合、理想から逸脱する理由の1つにすぎません。

個人的には、繰り返し参照される少数のエンティティに短い名前を頻繁に使用します。たとえば、頻繁に呼び出されるアプリ固有のサブルーチン。

4〜5文字未満の識別子名は使用しません。たとえば、ループ変数は、何かを達成するために必要な内部ループの数に応じて、IndexまたはjIndexまたはkIndexになりますが、他の名前には「キー」と言います「String LKey」または「int LKey」、メソッド変数の場合はローカルの「L」、プライベートクラス変数の場合は「F」、他のすべての識別子は、その名前に存在する理由を説明する必要があります。 「識別子」スコープは役に立たないですね。