私はCode Completeを読んでいて、レイアウトとスタイルの章で、彼はコードエディターが何らかのリッチテキスト形式を使用すると予測していました。つまり、このようなコードの代わりに

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

次のようになります。

手順 ResolveCollisions

空間分割アルゴリズムにより事後衝突解決を実行します

パラメーター

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

ローカル変数

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

構文の色付けと強調表示、さらには括弧の色付けさえ見ましたが、実際のコードではこのように見えませんでした。この種のものが実際に存在したのか、それとも十分な利益が得られなかったのか、それともまったく悪い考えだったのか、と思っていました。

このようなリッチなフォーマットのコードを以前に見たことがある人や、アイデアが検討されて最終的に拒否されたことがあるかどうかを知っていますか？

あなたができなかった技術的な理由はありません。テキストエディタが構文の強調表示を行える場合、表示の他の側面を簡単に変更してコードを強調表示できます。

ただし、エディターが入力内容を判断するので、入力されているものが何であれ色を変更することは1つのことです。入力中にテキストのサイズが突然変更され、ジャンプしてしまうと、本当に不快になります。

ただし、「静的」コード表示の場合は、ソースコードを簡単に美化できます。たとえば、中途半端なsource-> htmlコンバーターを使用して、好きなフォントサイズとスタイルをスタイルシートに追加すると、リッチなフォーマットコードが得られます。

単純な理由：エディター/ツールの独立。

コードを「リッチ」にすると、使用したエディターまたはリッチコードを理解できるエディターに関連付けられます。リッチさを処理できない他のすべてのエディターは、意味不明です。

同様に、リッチコードはdiffツールではうまく機能しません。たとえば、フォーマットを変更したばかりの場合、差分には違いが表示されますが、最も関心のある違いではありません。

バージョン管理はどうですか？書式設定のすべての変更を無視し、「実際の」変更がある場合にのみ変更されたファイルを表示するように指示する方法

最後に、豊富なコードのポイントは読みやすさだと思います。そのためには、より良い（さらに）コメント、論理識別子名、一貫したインデントで十分だと思います。

本質的に、プログラミングテキストはプレーンテキストとして最も適切に処理されます。見ているのは現実です。（これは、暗黙的よりも明示的というPythonicの考え方とも一致しています）

おそらく、リッチなフォーマットのコードは、それほどクールなアイデアではないため、受け入れられていません。個人的に、私はあなたが提供した例で私が見るものが好きではありません。私は構文の色付けと強調表示を使用しますが、その書式設定はあまりにも細工されており、コードの表示と作成に慣れている方法から大きく逸脱しています。

なぜ存在しないのですか？それに対する需要/必要性はありません。

現在のエディターは、構文の強調表示やその他のマイナーなスタイルのオプションでプログラマーのニーズを満たすことができます。それはすでに「リッチテキスト」ではありませんか？

これは、EmacsのAucTeXモードのLaTeXにはすでに存在します。セクションのタイトルのサイズが大きくなり、サブスクリプトとスーパースクリプトのサイズが適切に変更され、数学（および場合によってはAlgorithmicのような他の環境）のプレビューもほとんどできなくなります。

通常、コードから出力へのマッピングは他のプログラムよりもはるかに簡単なので、これはLaTeXには適しています。より汎用的な言語では、これはまったく好ましくないと思います。

Emacsが行うことができますもう一つは、のようなシンボル置き換えるある->とforallとを→し、∀それぞれHaskellで。Haskellではまったく必要ないことを除いて、この種のことをあなたが提案しているような書式設定に拡張できない理由はほとんどありません。

しばらく前、私はプログラマーがコードを入力したとおりにフォーマットすることを望んでいるかどうかを尋ねて、コードのフォーマットについてこの質問をしました。

私の質問はフォーマットのインデントの側面のみを取り上げましたが、一般的なコードのフォーマットにはいくつかの答えが当てはまるかもしれません。回答の全体的な感情は、プログラマーがコードの表現方法の絶対的な制御を失うことに反対していることを示唆しています。

私の個人的な経験はかなり異なっています。私は通常、公開されているツールを使用していますが、XSLTを独自のエディターで作成する必要がある場合があります。このエディターは、入力時に左余白をインデントすることでコードをフォーマットするので、不要な空白（XSLTで重要）の問題はなく、コードをワードラップしてフォーマットを維持できます。エクスペリエンスは非常に自然で、書式設定スタイルは改行のコンテキストと位置によってのみ制御されます（タッチセンシティブ入力デバイスを使用する場合、このエクスペリエンスは特にやりがいがあります）。

XSLTのバランスが取れていない場合、フォーマットは実際に問題の場所を示すのに役立ちます。入力中に水平方向のコードシフトに調整するのに少し時間がかかりましたが、それはもう気を散らすものではありません。ただし、XSLTの垂直方向の間隔に影響する書式設定機能により、エディターがほとんど使用できなくなったため、これらを無効にしました。

あなたの質問に戻ると、リッチコードの書式設定が一般的ではない理由は、プログラミングの世界で認識が変わるのに長い時間がかかるからだと思います。おそらくキーボードなしでコード編集が主に行われる時期と一致する可能性があります。

また、いくつかの言語（Haskell、Ruby、Python、Erlang、CoffeeScriptなど）ではインデントが重要です。そのため、フォントサイズを変更する場合、把握するのが非常に困難になる可能性があります。

主にその伝統。私はプロとして20年近くプログラミングを行ってきましたが、それが私を夢中にさせると思います。私はdocbookでEmacsまたはVIで本を書いているので、WYSIWIGファンではありません

KnuthのCWEBはこれを行いますが、C / C ++およびPascalでのみ機能します。—しかし、あなたはそれを見てみる必要があります...それは非常にきれいです。そこ二つのプログラムは、次のとおりctangleとcweaveされ、それぞれTeXとCへ/別のCWEBファイルを結合します。

このようなリッチなフォーマットのコードを以前に見たことがある人や、アイデアが検討されて最終的に拒否されたことがあるかどうかを知っていますか？

確かに。Xcodeは、さまざまな構文の単純な色付けを超えるスタイルをサポートしています。

使用してから長い時間が経ちましたが、Metrowerks CodeWarriorはスタイル付きテキストもサポートしていたと思います。これは10年以上前のことです。

ただし、スタイルを使いすぎたくはありません。スタイルがあまりにも異なると、テキスト、ソースコードなどが読みにくくなります。特に、サイズの混合は気を散らすものであり、列が整列しない原因となるものはどれも迷惑だと思います。ほとんどのプログラマーがまだ等幅フォントを使用しているのには理由があります。

別の質問は、スタイル付きテキストを言語構文自体の一部として使用する必要があるかどうかです。たとえば、一部のテキストが特定の方法でスタイル設定されているという事実をコンパイラが使用して、テキストが関数宣言であることを判断する必要がありますか？最初はおかしく聞こえるかもしれませんが、PythonやFortranなどの言語では、すでにインデントを構文として使用しています。それにもかかわらず、私たちは、スタイルが他の方法よりもむしろ構文によって駆動されるのを見続ける可能性が高いと思います。プレーンテキスト（より単純なコンパイラ、プラットフォームの独立性、プログラマーの好み）を使用できることから得られる多くの利点があり、スタイル（インデント、空白行、マーカー文字、コードの折りたたみやナビゲーションメニューなどのエディター機能）。

ソースコードの豊富な書式設定は、構造と意味がはるかに重要な（そして入力しやすい）情報入力を目的としているため、あまり一般的ではないと思います。フォント化、特別な記号、空白は、不要な視覚的ノイズを追加するだけです。ただし、生成されたドキュメントに適している場合があります。

WYSIWYGエディター（MS Wordなど）とTeX（LaTeX）のようなシステムを好む人たちの間で、植字の世界で同じトピックについて火炎戦争が終わることはありません。

一般的に、決定的な答えはありません。それはすべて、ツール、ユースケース、個人的な好みに依存します。

DoxygenやJavaDocなどのツールは、すでにリッチテキストコードの書式設定を実行しています。ブラウジング用にコードハイパーテキストも追加します。基本的な書式設定のために特別なタグを挿入する必要はありません。

ただし、これはWYSIWYGではありません。

私はこれが存在すると言うことを恐れています。

過去に、私はいくつかのCentura（GuptaまたはSQL / Windowsとしても知られています-古い " 4GL "）コードに取り組んできました。メモ帳のような標準エディターでCenturaコードを編集して、極端なレベルのフォーマットを必要とすることは実際には不可能でした。

ソースファイルをこのようにフォーマットすることは良い考えのように思えるかもしれませんが、開発は非常に制限的で苦痛であることがわかりました。

さらに、ソース管理でマージするときに、フォーマットが問題を引き起こすことがよくありました。

他の答えに加えて、豊富な書式設定を使用することの技術的な困難に加えて、個人的な好みの対象でもあることを指摘したいと思います。

プレーンテキストを編集する場合、好きなフォントと色を選択できます。これらは自動的に設定されます。リッチテキストを編集する場合、手動で設定される特定の色やフォントが気に入らない場合はどうでしょうか。

これは、コードの読み取りとコードの書き込みを分離した人がまだいないためだと思います。少なくとも主流にはなりません。ときどき、触れたコードや他の開発者が作成したコードを読む必要があります。このソースの1バイトを変更する準備が整うまで、おそらく多くの時間を費やす必要があります。これは、理解を容易にするために必要なこと（フォントサイズ、再フォーマット、サブスクリプト、スーパースクリプトなど）を実行できる「読み取り」モードである可能性があります。準備ができたら、エディターを「書き込み」モードに切り替えて、制限を緩和し、「最も驚きのルール」に従うことができます。