以前は、命令/レジスタ名を短くする非常に良い理由がありました。これらの理由はもはや当てはまりませんが、低レベルのプログラミングでは依然として短い暗号名が非常に一般的です。

どうしてこれなの？古い習慣が破れにくいからといって、それとももっと良い理由があるのでしょうか？

例えば：

• Atmel ATMEGA32U2（2010？）：（のTIFR1代わりにTimerCounter1InterruptFlag）、ICR1H（の代わりにInputCapture1High）、DDRB（の代わりにDataDirectionPortB）など。
• .NET CLR命令セット（2002）：（のbge.s代わりにbranch-if-greater-or-equal.short）など。

長くて、暗号化されていない名前を使用する方が簡単ではありませんか？

回答および投票する際は、以下を考慮してください。ここで提案されている説明の多くは高レベルのプログラミングにも同様に当てはまりますが、コンセンサスは概して、1つまたは2つの単語からなる非暗号化名を使用することです（一般に理解されている頭字語は除外されます）。

また、あなたの主な議論が紙の図の物理的な空間に関するものである場合、これはアセンブリ言語またはCILには絶対に適用されないことを考慮してください。さらに、簡潔な名前が収まるが読みやすいものが図を悪化させる図を見せていただければ幸いです。ファブレス半導体会社での個人的な経験から、読みやすい名前はうまく適合し、より読みやすい図になります。

高レベル言語ではなく、低レベルプログラミングで簡潔な名前を望ましいものにする高レベル言語とは異なる、中核となるものは何ですか？

ソフトウェアがこれらの名前を使用する理由は、データシートがそれらの名前を使用しているためです。とにかくデータシートなしではそのレベルのコードを理解することは非常に難しいため、検索できない変数名を作成することは非常に役に立ちません。

それは、データシートが短い名前を使用する理由の問題を提起します。これはおそらく、25文字の識別子を入れる余地がないこのようなテーブルに名前を表示する必要があることが多いためです。

また、回路図、ピン図、PCBシルクスクリーンなどは、スペースが非常に限られていることがよくあります。

ジップの法則

このテキストを見ると、単語の長さと使用頻度が一般に反比例していることがわかります。以下のような、非常に頻繁に使用される単語it、a、but、you、とはandあまり使用されている単語が好きながら、非常に短くobserve、comprehensionとverbosity長くなっています。この観測された頻度と長さの関係は、Zipfの法則と呼ばれます。

特定のマイクロプロセッサの命令セット内の命令の数は、通常数十または数百です。たとえば、Atmel AVR命令セットには、約100個の個別の命令が含まれているように見えます（数えませんでした）が、それらの多くは共通のテーマのバリエーションであり、非常に似たニーモニックを持っています。たとえば、乗算命令には、MUL、MULS、MULSU、FMUL、FMULS、およびFMULSUが含まれます。「BR」で始まる命令は分岐であり、「LD」で始まる命令はロードなどであるという一般的な考え方を得る前に、命令のリストを非常に長く見る必要はありません。変数にも同じことが当てはまります。複雑なプロセッサでも、条件レジスタ、汎用レジスタなど、値を格納する場所は限られています。

命令が非常に少なく、長い名前は読むのに時間がかかるため、短い名前を付けるのが理にかなっています。対照的に、高レベル言語を使用すると、プログラマは膨大な数の関数、メソッド、クラス、変数などを作成できます。これらのそれぞれは、ほとんどのアセンブリ命令よりもはるかに少ない頻度で使用され、リーダー（およびライター）が何であり、何をするのかを理解するのに十分な情報を提供するために、より長く、より説明的な名前がますます重要になります。

さらに、異なるプロセッサの命令セットでは、多くの場合、同様の操作に同様の名前が使用されます。ほとんどの命令セットには、ADD、MUL、SUB、LD、ST、BR、NOPの操作が含まれており、それらの正確な名前を使用しない場合、通常は非常に近い名前を使用します。1つの命令セットのニーモニックを学習したら、他のデバイスの命令セットに適応するのにそれほど時間はかかりません。あなたに「不可解」に見えるかもしれませんが名前のような言葉と同じくらい理解しているのでand、or、およびnot低レベルのプログラミングの技術に熟練しているプログラマに。アセンブリレベルで働くほとんどの人は、コードを読むことを学ぶことは低レベルプログラミングの大きな課題の1つではないと言うでしょう。

一般に

ネーミングの品質は、説明的な名前を持つことだけではなく、他の側面も考慮する必要があり、次のような推奨事項につながります。

• スコープがグローバルであるほど、名前はよりわかりやすくなります
• 頻繁に使用されるほど、名前は短くなります
• 同じ名前をすべてのコンテキストで同じものに使用する必要があります
• コンテキストが異なる場合でも、異なるものには異なる名前を付ける必要があります
• 変動を簡単に検出する必要があります
• ...

これらの推奨事項は矛盾していることに注意してください。

命令ニーモニック

アセンブリ言語プログラマとして、short-branch-if-greater-or-equalfor bge.sを使用すると、Algolプログラマが計算ジオメトリを実行するSUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTS代わりに、私が見るときと同じ印象を与えますdx := p2.x - p1.x。私が気にする文脈で最初のものがより読みやすいことに同意できない。

登録名

ドキュメントから正式名を選択します。ドキュメントはデザインから名前を選択します。デザインでは、長い名前では不十分な多くのグラフィカル形式を使用します。デザインチームは、数年ではないにしても、数か月はそれらの名前で生き続けます。両方の理由で、彼らは「最初のタイマーカウンターの割り込みフラグ」を使用せず、彼らはそれを彼らのスキーマで話すときと同様に短縮します。彼らはそれを知っていて、TIFR1混乱の可能性が少ないように体系的な略語を使用しています。ここでの1つのポイントTIFR1は、ランダムな略語ではなく、命名スキームの結果であるということです。

「古い習慣」の理由は別として、30年前に記述され、現在も使用されているレガシーコードは非常に一般的です。一部の経験の浅い人々が考えていることにもかかわらず、これらのシステムをきれいに見えるようにリファクタリングすることは、わずかな利益のために非常に高いコストがかかり、商業的に実行可能ではありません。

ハードウェアの近くにあり、レジスタにアクセスする組み込みシステムは、非常に良い理由から、ハードウェアデータシートで使用されているものと同じまたは類似のラベルを使用する傾向があります。レジスタがハードウェアデータシートでXYZZY1と呼ばれる場合、それを表す変数はXYZZY1である可能性が高く、プログラマーが良い日を過ごしている場合はRegXYZZY1です。

限りbge.s、それはアセンブラーに似ています-それを知っている必要がある少数の人々にとって、より長い名前は読みにくくなります。あなたが頭を動かせず、違いを生むbge.sと思うbranch-if-greater-or-equal.shortなら、あなたは単にCLRで遊んでいて、それを知らないだけです。

短い変数名が表示されるもう1つの理由は、ソフトウェアが対象としているドメイン内の略語が広く普及しているためです。

要約すると、業界の標準やハードウェアデータシートなどの外部の影響を反映した短い短縮変数名が必要です。ソフトウェアの内部にある短い短縮変数名は、通常はあまり望ましくありません。

ここには非常に多くの異なるアイデアがあります。私は、既存の回答のいずれかを受け入れることができないの答え：まず、これに貢献する可能性が高い多くの要因があり、そして第二に、私は、おそらく最も重要な一つである1を知ることができません。

だから、ここに他の人が投稿した回答の要約があります。私はこれをCWとして投稿していますが、最終的には承認済みとしてマークするつもりです。何か見落とした場合は編集してください。私はそれぞれのアイデアを簡潔かつ明確に表現するために言い換えることを試みました。

では、なぜ低レベルのプログラミングで不可解な短い識別子がそれほど一般的なのでしょうか？

• それらの多くはそれぞれのドメインで非常に一般的であるため、非常に短い名前を保証します。これは学習曲線を悪化させますが、使用頻度を考えると価値のあるトレードオフです。
• 通常、修正される可能性の小さなセットがあるためです（プログラマはセットに追加できません）。
• 可読性は習慣と実践の問題だからです。branch-if-greater-than-or-equal.shortは最初はより読みやすくなってbge.sいますが、一部のプラクティスでは状況は逆転します。
• なぜなら、低レベルの言語にはオートコンプリートの優れた強力なIDEが付属していないか、またはa / cが信頼できないためです。
• 多くの情報を識別子にパックすることが望ましい場合があり、高レベルの標準であっても、読み取り可能な名前は容認できないほど長いためです。
• それは歴史的に低レベルの環境がどのように見えてきたからです。習慣を打破するには、意識的な努力が必要であり、古い方法が好きな人を悩ませるリスクがあり、価値があると正当化する必要があります。確立された方法に固執することが「デフォルト」です。
• それらの多くは、回路図やデータシートなど、他の場所で作成されているためです。これらは、スペースの制約の影響を受けます。
• ものの命名を担当する人々は、読みやすささえ考えたことがないか、問題を引き起こしている、または怠けていることに気付かないからです。
• いくつかの場合、名前は、一部のコンパイラによる中間表現としてのアセンブリ言語の使用など、データ交換のためのプロトコルの一部になっているためです。
• このスタイルは低レベルとしてすぐに認識できるため、オタクにはクールに見えるからです。

個人的には、これらのいくつかは、新しく開発されたシステムがこの命名スタイルを選択する理由に実際には寄与していないと感じていますが、このタイプの回答でいくつかのアイデアを除外するのは間違っていると感じました。

私はこの混乱に帽子を投げるつもりです。

高レベルのコーディング規約と標準は、低レベルのコーディング標準と実践とは異なります。残念ながら、それらのほとんどは、レガシーコードと古い思考プロセスからの持ち越しです。

ただし、一部は目的に役立ちます。確かにBranchGreaterThanはBGTよりもはるかに読みやすくなりますが、現在は慣習があり、それは指示であり、過去30年間の標準としてある程度の牽引力を獲得しています。なぜそれから始めたのか、おそらく命令、変数などの任意の文字幅制限。なぜ彼らはそれを維持するのか、それは標準です。この標準はintを識別子として使用するのと同じです。すべての場合にIntegerを使用する方が読みやすいですが、数週間以上プログラミングしている人には必要です。どうして？それは標準的な慣行だからです。

第二に、私のコメントで述べたように、割り込みの多くはINTG1および他の不可解な名前と呼ばれ、これらも目的を果たします。回路図では、線に名前を付けることは良い慣習ではありません。そのため、冗長になり、図が煩雑になり、読みにくくなります。すべての冗長性はドキュメントで処理されます。また、すべての配線/回路図には割り込みラインのこれらの短い名前があるため、割り込み自体も、回路図からそれをプログラムするコードまでの組み込み設計者の一貫性を保つために同じ名前を取得します。

設計者はこれをある程度制御できますが、他のフィールド/新しい言語と同様に、ハードウェアからハードウェアへと続く規則があります。したがって、各アセンブリ言語間で同じままである必要があります。私はアセンブリのスニペットを見ることができ、その命令セットを使用することなくコードの要点を取得することができます。なぜなら、それらは慣習、LDA、またはそれとの何らかの関係に固執しているため、おそらくMVがどこかから何かを移動している可能性がありますどこか他の場所では、それはあなたが素晴らしいと思うか、高レベルの実践であるかではなく、それ自体が言語であり、それ自体に標準があり、デザイナーが従うべきであるということを意味します。彼らは思われる。

私はあなたにこれを残します：埋め込みコミュニティに冗長で高レベルのプラクティスを使用するように依頼することは、化学者に常に化学化合物を書き出すように依頼するようなものです。化学者はそれらを自分自身のために短く書きます、そして、フィールドの誰でもそれを理解します、しかし、それは調整するために新しい角を少し取るかもしれません。

彼らが不可解な短い識別子を使用する理由の1つは、開発者にとって不可解ではないためです。あなたは彼らが毎日それで動作し、それらの名前が本当にドメイン名であることを認識しなければなりません。したがって、彼らはTIFR1の正確な意味を心から知っています。

新しい開発者がチームに来た場合、彼はデータシートを読む必要があります（@KarlBielefeldtによる説明）。

実際、この種のソースコードでは、通常、ドメイン以外のものには多くの不要な暗号化識別子が表示されるため、あなたの質問は悪い例を使用したと思います。

コンパイラが入力したすべてを自動補完しなかったときに存在した悪い習慣のために、ほとんどの人がそうしていると思います。

概要

初期主義は、多くの技術的および非技術的分野で広まっている現象です。そのため、低レベルのプログラミングに限定されません。一般的な議論については、ウィキペディアのAcronymに関する記事を参照してください。私の答えは、低レベルのプログラミングに固有です。

暗号名の原因：

1. 低レベルの命令は強く型付けされています
2. 低レベルの命令の名前に多くの型情報を詰め込む必要がある
3. 歴史的に、タイプ情報のパッキングには単一文字コードが好まれています。

ソリューションとその欠点：

1. 歴史的なものよりも一貫性のある最新の低レベルの命名スキームがあります。
   • LLVM
2. ただし、多くの型情報をパックする必要がまだあります。
   • したがって、謎めいた略語はどこにでもあります。
3. 行間の読みやすさの改善は、初心者の低レベルプログラマーが言語をより早く習得するのに役立ちますが、低レベルコードの大部分を理解するのには役立ちません。

完全な答え

（A）より長い名前も可能です。たとえば、C ++ SSE2組み込み関数の名前は、アセンブリニーモニックの7文字と比較して平均12文字です。 http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

（B）次に質問に進みます。低レベルの指示からどれくらいの時間/非暗号化を取得する必要がありますか？

（C）次に、このような命名スキームの構成を分析します。以下は、同じ低レベル命令の2つの命名スキームです。

• 命名スキーム＃1： CVTSI2SD
• 命名スキーム＃2： __m128d _mm_cvtsi32_sd (__m128d a, int b);

（C.1）低レベルの命令は常に強く型付けされます。あいまいさ、型推論、自動型変換、またはオーバーロード（命令名の再利用は、類似しているが同等ではない操作を意味する）はあり得ません。

（C.2）各低レベル命令は、多くの型情報をその名前にエンコードする必要があります。情報の例：

• アーキテクチャファミリー
• 操作
• 引数（入力）と出力
• タイプ（符号付き整数、符号なし整数、浮動小数点数）
• 精度（ビット幅）

（C.3）各情報が綴られている場合、プログラムはより冗長になります。

（C.4）さまざまなベンダーが使用するタイプエンコーディングスキームには、長い歴史的なルーツがありました。例として、x86命令セットでは：

• Bはバイト（8ビット）を意味します
• Wはワード（16ビット）を意味します
• Dはdword "double-word"（32ビット）を意味します
• Qはqword "quad-word"（64ビット）を意味します
• DQはdqword「ダブルクワッドワード」（128ビット）を意味します

これらの歴史的参照には、現代的な意味はまったくありませんでしたが、依然として残っています。より一貫性のあるスキームでは、ビット幅の値（8、16、32、64、128）が名前に含まれます。

それどころか、LLVMは低レベルの指示の一貫性の方向への正しいステップです：http : //llvm.org/docs/LangRef.html#functions

（D）命令の命名スキームに関係なく、低レベルのプログラムは実行の詳細に焦点を当てているため、すでに冗長で理解しにくいものです。命令の命名スキームを変更すると、行レベルでの読みやすさが向上しますが、大きなコードの操作を理解する難しさはなくなりません。

人間がアセンブリを読み書きするのはたまにしかなく、ほとんどの場合、それは単なる通信プロトコルです。つまり、コンパイラーとアセンブラー間の中間シリアル化テキストベースの表現として最もよく使用されます。この表現がより詳細であるほど、このプロトコルではより不必要なオーバーヘッドが発生します。

オペコードとレジスタ名の場合、長い名前は実際に読みやすさを損ないます。短いニーモニックは、通信プロトコル（コンパイラーとアセンブリーの間）に適しています。アセンブリ言語は、ほとんどの場合、通信プロトコルです。コンパイラコードは読みやすいため、プログラマには短いニーモニックが適しています。

ほとんどは慣用的です。@TMNが他の場所で言っているように、あなたが書いimport JavaScriptObjectNotationたりimport HypertextTransferProtocolLibraryPythonで書いたりしないのTimer1LowerHalf = 0xFFFFと同じように、Cで書いてはいけません。文脈においても同様にばかげているように見えます。知る必要がある人は皆知っています。

一部の組み込みシステムのCコンパイラベンダーは、組み込みプログラミングに役立つ機能を実装するために、言語の標準と構文から逸脱しているという事実から、変更に対する抵抗が生じる可能性があります。これは、低レベルのコードを記述するときに、お気に入りのIDEまたはテキストエディターのオートコンプリート機能を常に使用できるとは限らないことを意味します。これらのカスタマイズはコードを分析する機能を無効にするためです。したがって、短いレジスタ名、マクロ、および定数のユーティリティ。

たとえば、HiTechのCコンパイラには、メモリ内でユーザーが指定した位置を持つ必要がある変数の特別な構文が含まれていました。あなたは宣言するかもしれません：

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

現在、これを解析する存在する唯一のIDEはHiTechのIDE（HiTide）です。他のエディターでは、毎回、メモリーから手動で入力する必要があります。これは非常に早く老化します。

さらに、開発ツールを使用してレジスタを検査する場合、複数の列（レジスタ名、16進数の値、バイナリの値、16進数の最後の値など）を含むテーブルが表示されることがよくあります。長い名前は、名前の列を13文字に拡張して2つのレジスタの違いを確認し、繰り返される単語の数十行にわたって「違いを見つける」必要があることを意味します。

これらは馬鹿げた小さな口論のように聞こえるかもしれませんが、すべてのコーディング規約が眼精疲労を減らし、余分なタイピングを減らし、または他の無数の小さな苦情に対処するように設計されているわけではありませんか？

誰も怠lazに言及しておらず、他の科学が議論されていないことに驚いています。プログラマーとしての私の日々の仕事は、プログラム内のあらゆる種類の変数の命名規則が3つの異なる側面の影響を受けることを示しています。

1. プログラマーの科学的背景。
2. プログラマーのプログラミングスキル。
3. プログラマーの環境。

低レベルまたは高レベルのプログラミングについて議論するのは役に立たないと思います。最後に、常に前の3つの側面に固定することができます。

最初の側面の説明： 多くの「プログラマー」はそもそもプログラマーではありません。彼らは数学者、物理学者、生物学者、あるいは心理学者や経済学者でさえありますが、それらの多くはコンピューター科学者ではありません。それらのほとんどには、独自のドメイン固有のキーワードと略語があり、それらは「コンベンション」という命名で見ることができます。彼らはしばしば彼らの領域に閉じ込められ、読みやすさやコーディングガイドを考えずにそれらの既知の略語を使用します。

2番目の側面の説明： ほとんどのプログラマーはコンピューターサイエンティストではないため、プログラミングスキルは制限されています。そのため、彼らはしばしばコーディング規約を気にしないが、最初の側面として述べられているように、ドメイン固有の規約については気にしません。また、プログラマーのスキルを持っていない場合は、コーディング規約を理解していません。私は彼らのほとんどが理解できるコードを書く緊急の必要性を見ていないと思う。そのような火と忘れます。

3番目の側面の説明： サポートする必要のある古いコード、会社のコーディング標準（コーディングを気にしないエコノミストによって運営されている）、または所属するドメインなど、環境の慣習にブレーキをかけることはほとんどありません。誰かが不可解な名前を使い始めて、あなたが彼または彼のコードをサポートしなければならない場合、あなたは不可解な名前を変更することはほとんどありません。あなたの会社にコーディング標準がない場合、ほとんどすべてのプログラマーが独自の標準を作成することになります。最後に、ドメインユーザーに囲まれている場合は、使用する以外の別の言語を書き始めることはありません。