IDEで等幅フォントを使用する理由 [閉まっている]

SOに関するフォントのトピックをいくつか見てきましたが、大多数の人がプログラミングタスクにモノスペースフォントを使用しているようです。私はプログラミングにVerdanaを数年間使用しており、モノスペースに関連するものを見逃すことなく、読みやすさの向上が本当に気に入っています。

なぜ等幅フォントを使用するのですか？

等幅フォントの場合：

• 等しい長さの文字列リテラルは等しく見えます。
• ：（）{}のような細い句読点が見やすくなります。
• 類似の文字はより異なって見えます：Il 0O vs Il 0O
• X文字幅のウィンドウで行が折り返されるかどうかはわかります。これは、チームがたとえば100文字の線で標準化でき、線が常に線のように見えることを意味します

私はこれまでプロポーショナルフォントでコーディングすることさえ考えたことがありません。それで、科学の利益のために、私はちょうどそれをやってみるために私の編集者を切り替えました。

簡単なチケットをいくつか修正した後のいくつかの所見を次に示します。

• コードは非常に密集しているようです。私のコードのほとんどは約80列で、100を超えることはめったにありません。プロポーショナルフォントは、エディターの左側にある小さなストリップにコードを押しつぶします。画面スペースが短い場合に役立つかもしれませんが、不必要にコンパクトに見えます。
• コードの「テクスチャ」は失われます。私が見ている構造の種類を判断するのは難しいです-それはほとんど文字ごとに読む必要があるテキストの単なる大きなスラブです。
• それはです非常に欠場するのは簡単!でオペレータをif (!foo)。（（！foo）の場合、参照してください！）
• 句読文字の定義が非常に不適切です。多くは区別するのが難しい（{}[]()vs {} []（））
• 一部の句読文字は他の文字よりもはるかに大きく、意図されていない場合に強調を推測します（$@%vs $ @％）
• 一部の文字は非常に狭く、識別が非常に困難です（'"!;:,.vs '"！;：、。）
• いくつかの数字と文字は非常に似ています（0Oo iIlvs 0Oo iIl）
• 私は構文の強調表示に非常に依存しています。それがなければ、引用符のバランスが取れていることを確認するなどのことを行うことはほぼ不可能です。
• 位置合わせ（単純なインデントは別として）は完全に壊れています。余分なスペースを入れることで翼を並べ替えることができますが、フォントの比例的な性質のため、行が正確に整列しない場合があります-コードは乱雑に見えます。
• 正規表現は..面白いです！

ありますいくつかの肯定的な点は、しかし、。確かに私はそれをほんの少ししか使っていませんが、プロポーショナルフォントで少しうまくいくいくつかの側面が確かにあります：

• 「単語」は読みやすくなります-スペルミス（変数のスペルが間違っているなど）が飛び出します。
• より長く、より説明的な変数名を使用する方が良いと思います（おそらく、スキャンが優れているため、テキストの水平サイズが圧縮されているため）
• このようなコードを読む方が少し簡単なようです。私の脳は、各単語を「トークン化」してその意味を理解する方が簡単です。句読文字は読みにくいため、それでも難しいのですが、慣れるまで少し時間がかかると、おそらくそれは変わるでしょう。

明日またこの回答を更新します（このように一日中やり遂げることができると仮定します！）

グループ化されていることをより明確にするために、関連する条件を並べるのが好きです。例えば：

if ((var1 == FOO) && ((var2 == BAR) ||
                      (var2 == FOOBAR)))

可変幅のフォントはこれをより困難にします。

ここで私が見続けていることの1つは、「コードの整列」とインデントについての議論です。私は次のことを指摘したいと思います：

• 8つのスペースは、どのフォントでも常に4つのスペースの2倍の長さになります。
• 2つのタブは、どのフォントでも常に1つのタブの2倍の長さになります。
• 1行の識別子は、次の行でも常に同じ幅になります...どのフォントでも！
• 確かに、チームメイトがモノスペースを使用していて、使用していない場合は、見た目が異なります...しかし、何かを標準化する必要があります-それが何であれ-それが本当なら、それは誰にとっても同じように見えます。 ..任意のフォントで！笑いのために、全員をモノスペースに保ち、半分をワイドスクリーンモニターにすることもできます...それがどうなるか見てみましょう。
• 使用している識別子のスコープではなく、画面上のそれらの文字の列の位置に基づいてコードを並べることに依存する何かをしている場合、私はあなたがしていることはハックだと思います。識別子は、名前の品質を犠牲にして、特定の文字数に制限されるべきではありません。それを除けば...あなたはまだあなたのコードのコメントのためにアスタリスクでASCIIボックスを描いていませんね？

したがって、これらすべてをまとめて描画します。各行を同じ場所から開始し、一定の間隔が同じ幅であり、識別子が各行の幅を自発的に変更しない場合、コードは実際に整列します。...何かが変わるまで。

例えば：

identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //how lined up and pretty!
identifier.Method().Sumthing.YouGetThePoint;

• 識別子.Method（）。Property.ToString（）;
• 識別子.Method（）。OtherGuy.ToString（）; //大野！ずれている！
• 識別子.Method（）。Sumthing.YouGetThePoint; // ...しかし、誰が気にしますか？それらは異なるプロパティです！

私が認める1つのポイントは、英数字以外の文字は通常、それほど広くないということです。これらには）（] [} {、：| "; '、`！とが含まれます。ただし、これはフォントエディタで修正できます...単に幅を広くするだけです。これは非等幅に固有の問題ではありません。それに対する需要はあまりなかったので、まだ行われていません。

要約すると、個人的な好みは問題ありませんが、非モノスペースよりもモノスペースを好む実用的な理由はほとんどないと思います。あなたはそれの外観が好きですか？確かに、モノスペースを実行します。画面にもっと多くのものを収めたいですか？非モノに行きます。しかし、人々が非モノスペースを異端のように扱う方法は少し誇張されています。

等幅フォントの多くの議論は、微調整を加えることで簡単に反論できるため、このスレッドに興味を持ちました。そこで、IDEをCalibriに切り替えました（顔が丸く、UIの画面で読みやすくなるように最適化されているため、完璧です）。今、私は明らかにインデントのためにスペースの代わりにタブを使用する必要があり（すべての問題を無視して）、4スペースの幅では明らかに十分ではないので、10に切り替えました。

今はかなりよさそうだ。しかし、私が見つけることができるいくつかの明らかな問題があります。この設定をしばらくテストした後、さらに多くのことが明らかになる可能性があります。

• すでに述べたように、一部の文字（特に括弧、セミコロン）は非常に細く見えます。これは連続したテキストで必要ですが、ソースコードでは必要ありません。これが最大の問題になると思います。

• シンボルがうまく整列しません。例として、次のC＃コードについて考えてみます。

  var expr = x => x + 1;
  

  矢印（=>）は、ほぼすべての等幅フォントの単位のように見えます。他のフォントの2つの隣接する文字のように見えます。>>などの演算子についても同じことが言えます。

• スペースは小さく見えます。読みやすさを向上させるために、ソースコードの間隔を空けています。これは、プロポーショナルフォントに切り替えるときに意味がありません。スペースの幅を制御できれば、これは間違いなく役に立ちます。

• 状況依存のインデントは完全に壊れています。一部のコンテキストでは、固定数のタブをインデントするだけでは不十分です。次のようにインデントされる可能性のあるLINQ式を使用します。

  var r = from c in "This, apparently, is a test!"
          where !char.IsPunctuation(c)
          select char.ToUpper(c);
  

  プロポーショナルフォントではこれを行うことはできません。

全体として、文字が狭すぎます。繰り返しになりますが、追加の文字間隔が役立つ場合があり、パンクチュエーションの場合は間違いなく必要です。ただし、プロポーショナルフォントを読みやすくするためのこのすべての調整は、等幅フォントを自然にエミュレートするだけだと感じています。これまでに述べたすべての点に確かに当てはまります。

私はComicSans MSを使用しています。これは、小さなポイントサイズとしてはかなり合理的に見えます（見出しのサイズで「冗談」に見え始めるだけです）。見た目は簡単ですが、VSのドッキングされたパネルのいくつかを開いた状態で、テキストウィンドウに適度な量のコードが表示されるようにテキストを十分に小さくしてください。

ソリューションエクスプローラーパネルを外しても、水平スクロールなしで100列のテキストを読み取ることができます。移動すると、DXCore Documentorパネル（フォーマットされたXMLDOCを表示）を十分に大きく開いて、XMLdocsを文書化するのに十分なテキストを表示しながら読むことができます。

チームで作業する場合、等幅フォントを使用すると、使用する等幅フォントに関係なく、コードが明確になり、すべての人に正しくレイアウトされます。

可変幅フォントを使用すると、コードがわかりやすく見える場合がありますが、等幅フォントのユーザーが開いた場合、コードが同じように見える可能性は低くなります。

モノスペースフォントを使用する必要があることを理解するために必要なのは、リテラルに1つではなく2つのスペースがあるために、検索で何かが見つからない理由を理解するために数時間かかることです。デザイナーがモノスペースフォントを使用していなかったときに、Lotus Notesエージェントを修正しようとしたときに、これが一度発生しました。コードをCodeWrightに貼り付けて印刷するまで、問題が何であるかは明らかでした。

等幅フォントを使用すると、コードの整列がはるかに簡単になります。

これは、チームで作業する場合に特に当てはまります。チームの全員が異なるフォントを使用でき、それらがすべて等幅である限り、すべてが整列します。同様に、1人の人が多くの異なる開発ツールを使用する場合、それらがすべて等幅であれば、すべてが整列します。それらがすべて等幅でない場合は、すべてが同じフォントを使用していることを確認する必要があります。2つのプラットフォームで開発している場合、それは難しい場合があります。

実際、一部の開発ツールは等幅フォントのみをサポートしています。

もう1つの理由は、等幅フォントはより明確な文字を持つ傾向があることです。lIiO0をlIiO0と比較すると、私が何を意味するかがわかります。また、空白のカウントがはるかに簡単になります。

テキストベースのDOS時代からの引き継ぎとして、等幅フォントがプログラマーの好みだったのではないかと思います。

一方、私自身、Verdanaと他のいくつかの推奨プロポーショナルフォントを試しましたが、変更に対処できませんでした。私の目はモノスペースにはあまりにもよく訓練されています。C / C ++、C＃、Perlなど、記号が多い言語は、私にはあまりにも異なって見えます。シンボルの配置により、コードの外観が完全に異なります。

正規言語よりもコードの性質上、正しく並べておくとよいでしょう。また、コード編集では、ブロック選択、ブロックコピー、ブロック貼り付けが必要になる場合があります。Visual Studioでは、マウスを選択しながらAltキーを使用してブロックを選択できます。エディターによって異なる場合がありますが、エディターでのそのオプションが非常に重要な場合があり、等幅フォントを使用しない限り、うまく機能しません。

個人的には、等幅フォントはコードエディタで読みやすいと思います。もちろん、私はほとんど盲目です。それは違いを生むかもしれません。私は現在、高コントラストの文字で暗い背景の15ポイントでconsolasフォントを実行しています。

インデントにスペースを使用すると、1レベルより深くなると問題になります。

主に位置合わせの目的で（関数パラメーター宣言が複数行にまたがっており、それらを並べたい場合や、コメントを並べる場合など）。

タブ文字の問題と同じように、複雑な要因は、位置合わせのために何かがインデントされ、他の誰かが異なる好みを持っている場合だと思います。物事がずれます。