短い変数名の言い訳はありますか？
これは、私が現在取り組んでいるコードベースに対する大きなフラストレーションになっています。私たちの変数名の多くは、短くて説明的ではありません。私がプロジェクトに残っている唯一の開発者であり、それらのほとんどが何をするかについてのドキュメントがないので、彼らが何を表しているかを追跡するために余分な時間を費やす必要があります。
たとえば、光学面の定義を更新するコードを読んでいました。最初に設定された変数は次のとおりです。
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は下付き文字としてレンダリングされます）、Routを外半径として認識します。 innerRadiusのようなものをより身近な命名法に精神的に翻訳できるようにすると、その人にとってコードがわかりにくくなります。おなじみの数式が正しくコーディングされていないケースを見つけるのが難しくなり、コード内の方程式を、論文や教科書にある方程式との間で変換することが難しくなります。
あなたがこのコードを見る唯一の人物である場合、コードと標準の光学方程式を変換する必要はありません。また、物理学者が将来コードを見る必要があるとは考えにくいでしょう。略語の利点がコストを上回らないため、リファクタリングする意味があります。ただし、これが新しい開発である場合は、文献で見つかるのと同じ略語をコードで使用することはほぼ間違いなく理にかなっています。
存続期間が短い変数には、短い名前を付ける必要があります。例として、for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { ...は記述しません。代わりに、for(int i ...を使用します。
一般的な経験則では、変数のスコープが短いほど、名前は短くなるはずです。多くの場合、ループカウンターはi、j、kのように1文字のみです。ローカル変数は、baseまたはfromとtoのようなものです。その場合、グローバル変数は、たとえばEntityTablePointerのように、もう少し複雑になります。
おそらく、このようなルールは、使用するコードベースに準拠していない可能性があります。しかし、これはリファクタリングを行う正当な理由です！
コードの問題は、短い名前ではなく、省略形を説明するコメントの欠如、または変数の導出元である数式についての役立つ資料への指摘です。
コードは単に問題ドメインの親しみやすさを前提としています。
特にコードを「所有」する人の役割では、コードを理解して維持するために問題ドメインの親しみやすさがおそらく必要となるため、名前を長くするのではなく、親しみやすさを身につける必要があります。
しかし、コードが踏み台として機能するためのいくつかのヒントを提供するなら、それは素晴らしいことです。ドメインの専門家でさえ、dKが円錐定数であることを忘れることがあります。コメントブロックに小さな「チートシート」を追加しても害はありません。
問題ドメインでよく知られている特定の変数（ここにある場合など）の場合、簡潔な変数名が妥当です。ゲームで作業している場合、ゲームエンティティにxおよびyではなく、位置変数horizontalPositionおよびverticalPositionを設定します。同様に、インデックス付け以外のセマンティクスを持たないループカウンターは、i、j、kが表示されることを期待しています。
「クリーンコード」によると：
変数名は：
- 意図を明らかにする
- 偽情報を避ける
- 意味のある区別をする
- はっきりと
- 検索できる
例外はことわざですi,j,k,m,n forループで使用されます。
当然のことながら、変数に名前を付けると、上記のことは何も行われません。それらの名前は悪い名前です。
また、すべてのメソッドは短くする必要がありますであるため、プレフィックスを使用してスコープまたはタイプのいずれかが使用されていないことを示します。
この名前はより良いです：
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クラス 、私はおそらく6ダースのリソース、Astronomy Almanac、および他の言語のスニペット（PHP、Java、Cなど）を参照しました）。
これらのほとんどすべてで、彼らは類似した同一の略語を使用しましたが、これは一見して絶対に何も意味しません。
K、T、EPS、deltaPsi、eot、LM、RA
ただし、物理学の知識があれば、それが何であったかを理解できます。他の誰かがこのコードに触れるとは思わないので、なぜ詳細な変数名を使用するのですか？
julianTime、nutationOfEclipticalLongitudeExpressedInDegrees、equationOfTime、longitudeMean、rightAscension。
さらに、多くの場合、変数名が一時的なもの、つまり一時的に値を割り当てるためにのみ使用される場合、特に変数のコンテキストが多い場合は、詳細バージョンを使用しても意味がありません。その目的を説明します。
絶対にあります。多くの場合、必要なのは短い変数名だけです。
私の場合、私はシニアRoboticsクラスでウェイポイントナビゲーションを行っており、KISS-Cでロボットをプログラミングしています。現在と目的地の（x、y）座標、（x、y）距離、現在と目的地の見出し、および回転角度の変数が必要です。
特にx座標とy座標の場合、長い変数名は完全に不要であり、xC（現在のx）、yD（宛先y）、pD（宛先phi）などの名前で十分であり、理解が最も簡単です。この場合。
プログラマのプロトコルが示すように、これらは「説明的な変数名」ではないと主張するかもしれませんが、名前は単純なコード（d =宛先、c =現在）に基づいているため、最初の非常に単純なコメントはすべての説明です彼らは必要とします。
変数にこのように名前を付けるのに十分な理由はありますか、それとも、それらを見つけたときにそれらをより説明的な名前に更新することで正当化されますか？
通常、複雑なアルゴリズムはmatlab（または同様の言語）で実装されます。私が見たのは、変数名を引き継ぐ人々です。そうすれば、実装を簡単に比較できます。
他のすべての答えはほぼ正しいです。これらの略語は、（例のように）dで始まっていないことを除いて、数学と物理学にあります。 dで始まる変数は、通常 微分 を表す名前が付けられています。
すべての通常のコーディングガイドでは、すべての最新のIDEでコードを簡単に参照できるため、変数を最初の文字がタイプを表すように指定しないでください（例のように）。
変数名がかなり短い理由を考えることができます。
短い名前は短いアイスパンを使用して読みやすいため、短い注意スパンになります。
たとえば、svdbが「データベースに保存」を意味することに慣れると、SaveToDatabaseを読み取るときではなく4文字（14文字、状況はさらに悪くなる）をすばやくスキャンするだけで済むため、ソースコードのスキャン速度が向上します。より複雑な操作名の場合）。 「読み取り」ではなく「スキャン」と言います。これは、ソースコードの分析の主要な部分を占めるためです。
大量のソースコードをスキャンする場合、これによりパフォーマンスが向上します。
また、コードを書くときに、怠惰なプログラマがこれらの短い名前を入力するのを助けるだけです。
もちろん、これらすべての「省略形」は、ソースコードの標準的な場所にリストされることが期待されています。
@zxcdwの発言を少し異なる方法で組み立て、アプローチの点で詳しく説明します。
関数は純粋、いくつかの機能の簡潔で完全なカプセル化である必要があります： ブラックボックスロジック 、それが手付かずのままであるかどうかに関係なくそのインターフェース（インとアウト）は健全であり、内部について何も知らないので、40年間、それは設計された仕事を続けます。
これはあなたが書きたい種類のコードです：これは持続するコードであり、移植するのは簡単です。
必要に応じて、 関数をother（インライン）関数呼び出し から構成して、コードを細かく保ちます。
スコープが非常に小さいため、適切に説明的な関数名（必要に応じて詳細に！）を使用して、短縮された変数名が誤って解釈される可能性を最小限に抑えます。