Warum sollten Sie in Ihrer IDE Monospace-Schriftarten verwenden? [geschlossen]

Ich habe einige Schriftartenthemen auf SO gesehen und es scheint, dass die Mehrheit der Leute Monospace-Schriftarten für Programmieraufgaben verwendet. Ich benutze Verdana seit ein paar Jahren zum Programmieren und ich mag die verbesserte Lesbarkeit sehr, ohne etwas zu verpassen, was mit Monospace zu tun hat.

Warum verwenden Sie eine Monospace-Schriftart?

In einer Monospace-Schrift:

• String-Literale gleicher Länge sehen gleich aus.
• Es ist einfacher, dünne Satzzeichen wie: () {} zu erkennen
• Ähnliche Charaktere sehen anders aus: Il 0O vs. Il 0O
• Sie wissen, ob eine Zeile in einem Fenster mit einer Breite von X Zeichen umbrochen wird. Dies bedeutet, dass Ihr Team beispielsweise 100 Zeichenzeilen standardisieren kann und eine Zeile immer wie eine Zeile aussieht

Ich habe noch nie darüber nachgedacht, in einer proportionalen Schriftart zu codieren. Im Interesse der Wissenschaft habe ich einfach meinen Editor umgestellt, um es auszuprobieren.

Hier einige Beobachtungen nach dem Reparieren einiger einfacher Tickets:

• Code scheint extrem dicht zu sein. Der größte Teil meines Codes besteht aus etwa 80 Spalten, selten über 100. Eine proportionale Schriftart zerquetscht ihn zu einem winzigen Streifen auf der linken Seite meines Editors. Vielleicht nützlich, wenn Sie wenig Platz auf dem Bildschirm haben, aber es scheint unnötig kompakt zu sein.
• Die 'Textur' des Codes geht verloren. Es ist schwer zu sagen, um welche Art von Struktur es sich handelt - es ist nur eine große Textplatte, die fast zeichenweise gelesen werden muss.
• Es ist sehr leicht, den !Bediener zu übersehen if (!foo). (if (! foo), siehe!)
• Interpunktionszeichen sind sehr schlecht definiert. Viele sind schwer zu unterscheiden ( {}[]()vs {} [] ())
• Einige Interpunktionszeichen sind viel größer als andere, was auf eine Betonung schließen lässt, bei der keine beabsichtigt ist ( $@%vs $ @%).
• Einige Zeichen sind sehr eng und sehr schwer zu identifizieren ( '"!;:,.vs '"!;:,.)
• Einige Zahlen und Buchstaben sind sehr ähnlich ( 0Oo iIlvs 0Oo iIl)
• Ich bin sehr darauf angewiesen , Syntaxhervorhebung, ohne sie es fast unmöglich ist , Dinge wie confirm Zitate zu tun ausgeglichen werden, usw.
• Die Ausrichtung (abgesehen vom einfachen Einrücken) ist vollständig unterbrochen. Sie können es beflügeln, indem Sie zusätzliche Leerzeichen einfügen . Aufgrund der Proportionalität der Schriftarten sind die Zeilen möglicherweise nicht genau ausgerichtet - der Code sieht unordentlicher aus .
• Reguläre Ausdrücke sind .. interessant!

Es gibt jedoch einige positive Punkte. Zugegeben, ich benutze es erst seit einiger Zeit, aber es gibt sicherlich einige Aspekte, die mit proportionalen Schriftarten etwas besser funktionieren:

• 'Wörter' sind leichter zu lesen - Rechtschreibfehler (z. B. falsche Schreibweise einer Variablen) springen auf Sie zu.
• Ich fühle mich besser, wenn ich längere, aussagekräftigere Variablennamen verwende (vielleicht weil sie besser scannen, vielleicht weil die horizontale Größe des Textes komprimiert ist)
• Es scheint etwas einfacher zu sein, solchen Code zu lesen . Es ist für mein Gehirn einfacher, jedes Wort zu "symbolisieren" und seine Bedeutung zu verstehen. Obwohl die Interpunktionszeichen schwerer zu lesen sind, ist es immer noch schwierig - aber vielleicht ändert sich das, wenn man sich etwas Zeit nimmt, um sich daran zu gewöhnen

Ich werde diese Antwort morgen erneut aktualisieren (vorausgesetzt, ich kann einen ganzen Tag wie diesen überstehen!)

Ich mag es, verwandte Bedingungen auszurichten, um zu verdeutlichen, dass sie gruppiert sind. Zum Beispiel:

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

Schriftarten mit variabler Breite erschweren dies.

Eine Sache, die ich hier immer wieder sehe, ist die Diskussion über "Aneinanderreihen von Code" und Einrückung. Ich möchte auf Folgendes hinweisen:

• Acht Leerzeichen sind in jeder Schriftart immer doppelt so lang wie vier Leerzeichen.
• Zwei Registerkarten sind in jeder Schriftart immer doppelt so lang wie eine Registerkarte.
• Jeder Bezeichner in einer Zeile hat in der nächsten Zeile immer die gleiche Breite ... in jeder Schriftart!
• Sicher, wenn Ihre Teamkollegen Monospace verwenden und Sie nicht, wird es anders aussehen ... aber Sie sollten sich auf etwas standardisieren - was auch immer es ist - und wenn das wahr ist, wird es für alle gleich aussehen. ..in jeder Schriftart! Zum Lachen könnten Sie auch versuchen, alle auf Monospace zu halten und die Hälfte von ihnen Breitbildmonitore zu geben ... sehen Sie, wie das geht.
• Wenn Sie etwas tun, das darauf beruht, Code basierend auf der Spaltenposition dieser Zeichen auf dem Bildschirm und nicht auf dem Umfang der von Ihnen verwendeten Bezeichner auszurichten, ist das, was Sie tun, ein Hack. Bezeichner sollten niemals auf Kosten der Qualität ihrer Namen auf eine bestimmte Anzahl von Zeichen beschränkt werden. Abgesehen davon ... zeichnen Sie immer noch keine ASCII-Felder mit Sternchen für Kommentare in Ihrem Code, oder?

Wenn Sie also all dies zusammen zeichnen, wenn Sie jede Zeile an derselben Stelle beginnen und der konsistente Abstand dieselbe Breite hat und die Bezeichner die Breite in jeder Zeile nicht spontan ändern, wird Ihr Code tatsächlich ausgerichtet! ... bis etwas anders ist.

zum Beispiel:

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

• identifier.Method (). Property.ToString ();
• identifier.Method (). OtherGuy.ToString (); //Ach nein! verstellt!
• identifier.Method (). Sumthing.YouGetThePoint; //...aber wen kümmert's? Sie sind verschiedene Eigenschaften!

Der einzige Punkt, den ich zugeben werde, ist, dass nicht alphanumerische Zeichen normalerweise nicht sehr breit sind. Dazu gehören) (] [} {,: | "; ',`! und. Dies könnte jedoch in einem Schrifteditor behoben werden ... einfach indem man sie breiter macht. Es ist kein Problem, das mit Nicht-Monospace verbunden ist; es gibt nur keine Es war keine große Nachfrage danach, und so wurde es noch nicht getan.

Zusammenfassend ist die persönliche Präferenz in Ordnung, aber ich denke, es gibt wenig praktischen Grund, Monospace gegenüber Nicht-Monospace zu bevorzugen. Du magst das Aussehen? Klar, mach Monospace. Sie möchten, dass mehr Dinge auf Ihren Bildschirm passen? Gehen Sie nicht mono. Aber die Art und Weise, wie Menschen Nicht-Monospace wie Häresie behandeln, ist etwas übertrieben.

Ich bin durch diesen Thread neugierig geworden, weil viele Argumente für monospaced Schriftarten mit einigen Optimierungen wirklich leicht widerlegt werden können. Also habe ich meine IDE auf Calibri umgestellt (weil sie ein schönes, rundes Gesicht hat und für die Lesbarkeit auf Bildschirmen für die Benutzeroberfläche optimiert ist - perfekt). Jetzt muss ich natürlich Tabulatoren anstelle von Leerzeichen zum Einrücken verwenden (wobei alle Probleme ignoriert werden) und die Breite von 4 Leerzeichen reicht eindeutig nicht aus, also habe ich auf 10 umgestellt.

Sieht jetzt ganz gut aus. Es gibt jedoch einige offensichtliche Probleme, die ich erkennen könnte. Weitere könnten später auftauchen, nachdem ich diese Einstellungen für eine Weile getestet habe.

• Wie bereits erwähnt, sehen einige Zeichen (insbesondere Klammern, Semikolons) viel zu dünn aus. Ich möchte dies in einem fortlaufenden Text, aber nicht in einem Quellcode. Ich denke, das wird das größte Problem sein.

• Symbole sind nicht gut ausgerichtet. Betrachten Sie als Beispiel den folgenden C # -Code:

  var expr = x => x + 1;
  

  Der Pfeil ( =>) sieht aus wie eine Einheit in etwa jeder Monospace-Schriftart. Es sieht aus wie zwei benachbarte Zeichen in anderen Schriftarten. Gleiches gilt für Betreiber wie >>etc.

• Räume sehen winzig aus. Ich platziere meine Quellcodes intensiv, um die Lesbarkeit zu verbessern. Dies wird beim Umschalten auf eine proportionale Schriftart zunichte gemacht. Wenn ich die Breite der Räume steuern könnte, würde dies definitiv helfen.

• Die kontextsensitive Einrückung ist vollständig fehlerhaft: In einigen Kontexten reicht es nicht aus, eine feste Anzahl von Registerkarten einzurücken. Nehmen Sie LINQ-Ausdrücke, die möglicherweise wie folgt eingerückt werden:

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

  Mit einer proportionalen Schriftart ist dies einfach nicht möglich.

Alles in allem sind die Zeichen zu eng. Auch hier kann ein zusätzlicher Buchstabenabstand hilfreich sein, der im Falle einer Interpunktion unbedingt erforderlich ist. Ich habe jedoch das Gefühl, dass all diese Optimierungen, um proportionale Schriftarten besser lesbar zu machen, nur das emulieren würden, was monospaced Schriftarten natürlich sind. Dies gilt sicherlich für alle bisher genannten Punkte.

Ich verwende Comic Sans MS, das als kleine Punktgröße durchaus vernünftig aussieht (bei Überschriftengrößen sieht es erst "witzig" aus). Es schont die Augen und hält den Text dennoch klein genug, um eine angemessene Menge an Code im Textfenster sichtbar zu machen, wobei mehrere angedockte VS-Bedienfelder geöffnet sind.

Sie können das Projektmappen-Explorerfenster ausblenden lassen und trotzdem 100 Textspalten ohne horizontales Scrollen lesen. Außerdem kann ich das DXCore Documentor-Bedienfeld (das formatierte XMLDOCs anzeigt) weit genug öffnen, um es lesen zu können, während ich immer noch genug Text sehen kann, um die XMLdocs zu dokumentieren.

Wenn Sie in einem Team arbeiten, stellen Mono-Schriftarten sicher, dass der Code für alle klar und korrekt angeordnet ist, unabhängig davon, welche Mono-Schriftarten sie bevorzugen.

Ihr Code sieht für Sie möglicherweise klar aus, wenn Sie eine Schriftart mit variabler Breite verwenden. Es ist jedoch unwahrscheinlich, dass er gleich aussieht, wenn ein Benutzer mit Monoabstand ihn öffnet.

Es dauert nur ein paar Stunden, um herauszufinden, warum eine Suche etwas nicht findet, weil Sie 2 statt 1 Leerzeichen in Ihrem Literal haben, um zu erkennen, dass Sie Monospace-Schriftarten verwenden sollten. Dies ist mir einmal passiert, als ich versucht habe, einen Lotus Notes-Agenten zu reparieren, als der Designer keine Monospace-Schriftart verwendete. Erst als ich den Code in CodeWright einfügte, um ihn auszudrucken, war klar, wo das Problem lag.

Monospaced-Schriftarten erleichtern das Ausrichten von Code erheblich.

Dies gilt insbesondere für die Arbeit mit einem Team. Jeder im Team kann verschiedene Schriftarten verwenden, und solange sie alle monospaced sind, wird alles in einer Reihe stehen. Wenn eine einzelne Person viele verschiedene Entwicklungswerkzeuge verwendet, wird alles in einer Reihe stehen, wenn sie alle monospaced sind. Wenn sie nicht alle monospaced wären, müssten Sie sicherstellen, dass sie alle dieselbe Schriftart verwenden, und wenn Sie auf zwei Plattformen entwickeln, kann dies schwierig sein.

Tatsächlich unterstützen einige Entwicklungstools nur monospaced Schriftarten.

Ein weiterer Grund ist, dass monospaced Schriftarten tendenziell deutlichere Zeichen haben. Wenn Sie lIiO0 mit vergleichen lIiO0, werden Sie sehen, was ich meine. Sie machen es auch viel einfacher, Leerzeichen zu zählen.

Ich vermute, dass monospaced Schriftarten von Programmierern als Übertragung aus den textbasierten DOS-Tagen bevorzugt wurden.

Auf der anderen Seite habe ich selbst Verdana und einige andere empfohlene proportionale Schriftarten ausprobiert, aber ich konnte mit der Änderung nicht umgehen. Mein Auge ist für Monospace zu gut trainiert. Symbolreiche Sprachen wie C / C ++, C #, Perl usw. sehen für mich zu unterschiedlich aus. Durch die Platzierung von Symbolen sieht der Code völlig anders aus.

Aufgrund der Natur des Codes und nicht der normalen Sprache ist es besser, ihn richtig auszurichten. Bei der Codebearbeitung möchten Sie manchmal auch die Auswahl blockieren, das Kopieren und das Einfügen blockieren. In Visual Studio können Sie die Blockauswahl mit der ALT-Taste durchführen, während Sie die Maus auswählen. Es mag in verschiedenen Editoren unterschiedlich sein, aber ich fand diese Option in einem Editor in einigen Fällen immer sehr wichtig, und sie würde nicht sehr gut funktionieren, es sei denn, Sie verwenden eine Schriftart mit einem Abstand.

Ich persönlich finde die Mono-Spaced-Schriftarten in Code-Editoren leichter zu lesen. Natürlich bin ich fast blind. Das könnte einen Unterschied machen. Ich verwende derzeit Consolas-Schrift bei 15 Punkten mit dunklem Hintergrund und kontrastreichen Buchstaben.

Das Verwenden von Leerzeichen zum Einrücken wäre ein Problem, sobald Sie tiefer als eine Ebene sind.

Meistens zu Ausrichtungszwecken (z. B. wenn Funktionsparameterdeklarationen mehrere Zeilen umfassen und Sie sie aneinanderreihen möchten oder Kommentare usw. aneinanderreihen möchten).

Ich denke, genau wie bei der Ausgabe von Tabulatorzeichen ist der komplizierende Faktor, wenn etwas zum Zwecke der Ausrichtung eingerückt wird und jemand anderes andere Vorlieben hat. Die Dinge werden falsch ausgerichtet.