短い変数名の言い訳はありますか？

これは、現在作業しているコードベースに大きな不満を感じています。変数名の多くは短く、説明的ではありません。私はプロジェクトに残った唯一の開発者であり、それらのほとんどが何をするかについてのドキュメントがないため、それらが表すものを追跡するために余分な時間を費やす必要があります。

たとえば、光学面の定義を更新するコードを読んでいた。開始時に設定された変数は次のとおりです。

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

たぶんそれは私だけかもしれませんが、それが何を表しているのかを本質的に教えてくれなかったので、コードをさらに理解するのが難しくなりました。私が知っていたのは、それがどこか特定のテーブルから特定の行を解析する変数であることだけでした。いくつかの検索の後、私はそれらが何を意味するかを見つけました：

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

本質的にそこにあるものに名前を変更しました。それはいくつかの線を長くしますが、私はそれが公正なトレードオフだと感じています。ただし、この種の命名スキームは、多くのコードで使用されています。古いシステムで作業して学んだ開発者の成果物なのか、それともより深い理由があるのか​​はわかりません。このように変数に名前を付ける正当な理由はありますか、それとも変数に出会ったときにそれらをよりわかりやすい名前に更新することは正当ですか？

これらの変数名は、さまざまな光学の問題を扱う物理学の教科書に記載されている略語に基づいているようです。これは、長い変数名よりも短い変数名が望ましい場合が多い状況の1つです。Rin、Routなどの一般的な略語を使用することに慣れている物理学者（または方程式を手動で計算することに慣れている人）がいる場合、コードは長い変数名を使用する場合よりもそれらの略語を使用するとはるかに明確になります。また、論文や教科書の数式をコードと比較して、コードが実際に正しく計算を行っていることを確認するのがはるかに簡単になります。

光学に精通している人なら誰でもすぐに、Rin（物理学論文ではin下付き文字としてレンダリングされる）としてのRin 、外側半径としてのRoutなどを認識します。innerRadiusより馴染みのある命名法のように、そうすると、その人にとってコードが明確になりません。馴染みのある式が誤ってコーディングされているケースを見つけるのがより難しくなり、コード内の方程式を論文や教科書で見つけた方程式と相互に変換することがより難しくなります。

あなたがこのコードを見るのがあなただけなら、コードと標準的な光学方程式の間で翻訳する必要はありません。物理学者が将来コードを見る必要があることはまずありません。略語の利点がコストを上回らないため、リファクタリングする意味があります。しかし、これが新しい開発である場合、コードで同じ略語を使用することは、文献で見つけることとほぼ間違いなく意味があります。

寿命の短い変数には、すぐに名前を付ける必要があります。例として、を書かないfor(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { ...。代わりに、を使用しますfor(int i ...。

一般的な経験則では、変数スコープが短いほど名前は短くなると言えます。ループカウンターは、多くの場合、たとえばi、jおよびなどの1文字のみkです。ローカル変数のようなものがあるbaseかfromとto。グローバル変数は、たとえば、やや複雑EntityTablePointerです。

おそらく、このようなルールは、使用するコードベースに従っていません。ただし、リファクタリングを行う正当な理由です！

コードの問題は、短い名前ではなく、略語を説明するコメントの欠如、または変数の派生元の数式に関する有用な資料を指すことです。

このコードは、問題領域の知識があることを前提としています。

問題をよく知っていることは、特にコードを「所有する」人の役割で、コードを理解して維持するためにおそらく必要なので、名前を長くするのではなく、親しみを身につけなければなりません。

しかし、コードがスプリングボードとして機能するためのヒントを提供してくれると便利です。ドメインの専門家でさえ、それdKが円錐定数であることを忘れることがあります。コメントブロックに小さな「チートシート」を追加しても問題はありません。

問題の領域でよく知られている特定の変数については（ここにあるケースのように）、簡潔な変数名が妥当です。ゲームで作業している場合、ゲームエンティティに位置変数xand y、not horizontalPositionおよびを持たせverticalPositionます。インデックスを超えてどんな意味を持っていない同様にループカウンタは、私が見ることを期待しi、j、k。

「クリーンコード」によると：

変数名は：

• 意図を明らかにする
• 偽情報を避ける
• 意味のある区別をする
• 発音可能
• 検索可能

例外はi,j,k,m,nforループで使用されることわざです。

変数名は、当然のことながら、上記の何もしないことについて文句を言います。それらの名前は悪い名前です。

また、すべてのメソッドはshortでなければならないため、プレフィックスを使用してスコープまたはタイプが使用されなくなったことを示します。

この名前の方が優れています：

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

コメンターは、これは長い変数名では複雑すぎると言っています。

短い変数名でも単純になりません：

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

答えは、最後にこれを取得するまでの長い名前と中間結果です。

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

従来のコードで変数の名前を変更しないのには、2つの理由があります。

（1）自動リファクタリングツールを使用している場合を除き、バグが発生する可能性が高くなります。したがって、「破損していない場合は修正しないでください」

（2）変更点を確認するために、現在のバージョンと過去のバージョンを比較することは不可能です。これにより、コードの将来のメンテナンスがより困難になります。

このように変数に名前を付ける正当な理由はありますか、それとも変数に出会ったときにそれらをよりわかりやすい名前に更新することは正当ですか？

小さい名前を使用する理由は、元のプログラマーが作業しやすいと感じた場合です。おそらく彼らは、それが事実であると判断する権利と、あなたと同じ個人的な好みを持たない権利を持っています。個人的に、私は見つけるだろう...

dDin better than dDinnerAperture
dDout better than dDouterAperture

...長く複雑な計算でそれらを使用していた場合。数式が小さければ小さいほど、一度にすべてを簡単に見ることができます。ただし、その場合は、dInおよびdOutのように優れている可能性があるため、簡単なタイプミスにつながる可能性のある繰り返しDはありませんでした。

一方、作業するのが難しい場合は、自分自身をノックアウトして名前を変更し、長い形式に変更します。特にそのコードを担当している場合。

一般に、このルールは、特定のコードの「技術」を習得している人がその変数名の参照をすぐに理解することを知っている場合、非常に短い変数名を使用できるはずだと思います。（とにかくこのケースの例外については常にコメントがあります）、そして変数のローカライズされた使用法は、それらがどのように使用されるかのコンテキストに基づいて容易に識別できることを。

これを拡張するには、変数名を難読化するために邪魔にならないようにする必要がありますが、変数名には略語を使用できます。とにかくそれを読むために。

実世界の例を使用するために、最近、緯度を取り、特定の日に予想される日光の量を伝えるJavascriptクラスを作成していました。

このSundialクラスを作成するために、私はおそらく半ダースのリソース、天文学年鑑、および他の言語（PHP、Java、Cなど）のスニペットを参照しました。

これらのほとんどすべてで、彼らは同様の略語を使用しましたが、それは一見すると絶対的なものではありません。

K、T、EPS、deltaPsi、eot、LM、RA

ただし、物理学の知識があれば、それが何であるかを理解できます。他の誰かがこのコードに触れることを期待しないので、なぜ冗長変数名を使用するのですか？

julianTime、nutationOfEclipticalLongitudeExpressedInDegrees、equationOfTime、longitudeMean、rightAscension。

さらに、多くの場合、変数名が一時的である場合、つまり一時的に値を一時的に割り当てるためにのみ使用される場合、特に変数のコンテキストがその目的を説明します。

絶対にあります。多くの場合、必要なのは短い変数名だけです。

私の場合、シニアロボットクラスでウェイポイントナビゲーションを行っており、KISS-Cでロボットをプログラミングしています。現在および目的地（x、y）座標、（x、y）距離、現在および目的地の見出し、および回転角度の変数が必要です。

特にxおよびy座標の場合、長い変数名は完全に不要であり、xC（現在のx）、yD（宛先y）、pD（宛先phi）などの名前で十分であり、理解しやすいこの場合。

プログラマーのプロトコルが指示するように、これらは「記述的な変数名」ではないと主張するかもしれませんが、名前は単純なコードに基づいているため（d =宛先、c =現在）、最初の非常に単純なコメントがすべての説明です彼らが必要です。

このように変数に名前を付ける正当な理由はありますか、それとも変数に出会ったときにそれらをよりわかりやすい名前に更新することは正当ですか？

通常、複雑なアルゴリズムはmatlab（または同様の言語）で実装されます。私が見たのは、人々が変数名を引き継いでいるだけです。そうすれば、実装を簡単に比較できます。

他のすべての答えはほぼ正しいです。これらの略語は、数学や物理学で見つけることができますが、d（例のように）で始まっていません。通常、dで始まる変数には、微分を表す名前が付けられます。

すべての通常のコーディングガイドは、（すべての場合のように）型を表す最初の文字で変数に名前を付けないように指示しています。これは、現代のすべてのIDEでコードを簡単に参照できるためです。

変数名がかなり短い理由を考えることができます。

短い名前は短いアイスパンを使用して読みやすいため、短いアテンションスパンです。

たとえば、svdbが「データベースに保存」を意味するという事実に慣れると、SaveToDatabaseを読み取るときではなく、4文字だけをすばやくスキャンする必要があるため、ソースコードのスキャン速度が向上します（14文字、事態は悪化します）より複雑な操作名の場合）。「読み取り」ではなく「スキャン」と言います。これはソースコードの分析の大部分を占めるからです。

大量のソースコードをスキャンする場合、これによりパフォーマンスが向上します。

また、コードを書くときに怠zyなプログラマーがこれらの短い名前を入力するのに役立ちます。

もちろん、これらの「略記法」はすべて、ソースコードの標準的な場所にリストされることが期待されています。

@zxcdwの発言を少し異なる方法で組み立て、アプローチの観点から詳しく説明します。

関数は純粋で、簡潔で、一部の機能を完全にカプセル化する必要があります：ブラックボックスロジック、40年間そのままであるかどうかに関係なく、そのインターフェイス（インとアウト）のために設計された仕事を続けますあなたはその内部の何も知らないとしても、健全です。

これは、書きたいコードの一種です。これは持続するコードであり、移植が簡単です。

必要な場合、外機能を構成する他の（インライン）関数呼び出しきめ細かいコードを保つために、。

ここで、適切に記述的な関数名（必要に応じて冗長！）を使用すると、スコープが非常に小さいため、これらの短縮された変数名の誤解の可能性を最小限に抑えます。

変数名は、プログラムを読みやすくするために、できるだけわかりやすい名前にする必要があります。あなたはそれを自分で経験しました：貧弱なネーミングのためにプログラムが何をしたかを特定するのに多くの問題がありました。

わかりやすい名前を使用しない正当な理由はありません。それはあなたと、プロジェクトで働いている/働くすべての人を助けるでしょう。実際には、短い名前にはループカウンターという有効な使用方法が1 つあります。

確かにこれは//コメントの目的ですか？

割り当てに説明的なコメントが含まれている場合、両方の長所を活用できます。変数の説明と方程式は、対応するテキストブックと簡単に比較できます。

インターフェイス（メソッドシグネチャ、関数シグネチャなど）については、パラメーター宣言に注釈を付けることでこれを解決する傾向があります。C / C ++の場合、これは.hファイルと実装のコードを装飾します。

コンテキストとネーミングで変数の使用法がわからない変数宣言についても同じことを行います。（これは、強い型付けを持たない言語にも当てはまります。）

変数名を詰まらせたくないものがたくさんあります。ラジアンまたは度単位の角度、精度や範囲などの許容範囲があります。この情報は、正しく処理する必要がある特性に関する価値ある主張を提供できます。

私はそれについて宗教的ではありません。私は単に明快さに興味があり、私の忘れっぽい自己がコードを次に訪れるとき、それが今何であるかを確かめることに興味があります。そして、私の肩越しに見ている人は、何かがどこにあるのか、何が不可欠なのかを知るために知っておくべきことを持っています（適切なメンテナンスのための最後の重要）。

過度に短い変数名の言い訳はありますか？

まず、E = MC2などの式を計算するときにエネルギーeの変数に名前を付けることは、過度に短い名前ではありません。引数として記号を使用するための短い名前は有効ではありません

この質問は私にとってかなり興味深いものでした。1つの言い訳しか考えられず、それがお金です。

たとえば、ファイルが1秒に何回もダウンロードされることを知っているクライアントにjavascriptを配線しているとします。ファイル（バイト数）が可能な限り小さい場合は、より安価で、ユーザーエクスペリエンスが向上します。

（例を「現実的」に保つために、ミニファイツールを使用することは許可されませんでした。なぜですか？セキュリティの問題、コードベースに触れることができる外部ツールはありません。）

他の回答では、ハンガリー記法の使用について言及していないことに気付きました。これは長さの議論に直交していますが、一般的な命名スキームに関連しています。

double dR, dCV, dK, dDin, dDout, dRin, dRout

これらすべての変数の先頭にある「d」は、それらが二重であることを示すためのものです。とにかく言語はこれを強制しています。これらの名前は簡潔ですが、最大50％冗長です！

エラーを減らすために命名規則を使用する場合、言語によってチェックされていない情報をエンコードする方がはるかに優れています。たとえばdK + dR、上記のコードでは、長さに無次元数を追加しても意味がありませんが、文句を言う言語はありません。

このようなエラーを防ぐ良い方法は、より強力な型を使用することです。ただし、doubleを使用する場合、より適切な命名スキームは次のとおりです。

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

言語はまだ私たちが書くことを許可しますK + lRが、今では名前はこれが間違っているかもしれないというヒントを与えてくれます。

これは、Systems Hungarian（一般的に悪い）とApps Hungarian（おそらく良い）の違いです

http://en.wikipedia.org/wiki/Hungarian_notation

唯一の彼らは、スクリプト内に存在し、（一般的に、ネットワークを介して）、そのスクリプトのスループットが重要な場合illegibly短い変数名は、現代のソフトウェア工学における許容される場合があります。それでも、ソース管理では長い名前のスクリプトを使用し、本番環境ではスクリプトを縮小します。