Po co używać czcionek o stałej szerokości w swoim IDE? [Zamknięte]

Widziałem kilka tematów dotyczących czcionek w SO i wydaje się, że większość ludzi używa czcionek o stałej szerokości do zadań programistycznych. Używam Verdany do programowania od kilku lat i bardzo podoba mi się zwiększona czytelność, nie tracąc nic związanego ze stałą przestrzenią.

Dlaczego używasz czcionki o stałej szerokości?

W czcionce o stałej szerokości:

• Literały ciągów o jednakowej długości wyglądają na równe.
• Łatwiej jest zobaczyć cienkie znaki interpunkcyjne, takie jak: () {}
• Podobne postacie wyglądają bardziej inaczej: Il 0O vs Il 0O
• Wiesz, czy linia zostanie zawinięta w oknie o szerokości X znaków. Oznacza to, że Twój zespół może ustandaryzować na powiedzmy 100 linii znaków, a linia zawsze będzie wyglądać jak linia

Nigdy wcześniej nawet nie rozważałem kodowania czcionką proporcjonalną. Dlatego w interesie nauki po prostu przełączyłem edytor, żeby spróbować.

Oto kilka uwag po ustaleniu kilku łatwych biletów:

• Kod wydaje się niezwykle gęsty. Większość mojego kodu ma około 80 kolumn, rzadko ponad 100. Czcionki proporcjonalne ściskają go do małego paska po lewej stronie mojego edytora. Może przydatne, jeśli masz mało miejsca na ekranie, ale wydaje się niepotrzebnie kompaktowe.
• „Tekstura” kodu zostaje utracona. Trudno powiedzieć, na jaką strukturę patrzę - to po prostu duża porcja tekstu, którą trzeba czytać prawie znak po znaku.
• Jest to bardzo łatwo przegapić !Operatora if (!foo). (jeśli (! foo), zobacz!)
• Znaki interpunkcyjne są bardzo źle zdefiniowane. Wiele jest trudnych do odróżnienia (w {}[]()porównaniu z {} [] ())
• Niektóre znaki interpunkcyjne są znacznie większe niż inne, powodując podkreślenie tam, gdzie żaden nie jest przeznaczony (w $@%porównaniu z $ @%)
• Niektóre znaki są bardzo wąskie i bardzo trudne do zidentyfikowania ( '"!;:,.vs '"!;:,.)
• Niektóre cyfry i litery są bardzo podobne (w 0Oo iIlporównaniu z 0Oo iIl)
• Jestem niezwykle zależny od podświetlania składni, bez niego prawie niemożliwe jest wykonywanie takich rzeczy, jak potwierdzenie, że cytaty są zrównoważone itp.
• Wyrównanie (poza prostym wcięciem) jest całkowicie zepsute. Możesz to trochę zmienić, dodając dodatkowe spacje, ale z powodu proporcjonalnego charakteru czcionek linie mogą nie być dokładnie wyrównane - kod wygląda bardziej niechlujnie .
• Wyrażenia regularne są ... interesujące!

Jest jednak kilka pozytywnych punktów. Wprawdzie używam go dopiero od jakiegoś czasu, ale z pewnością są pewne aspekty, które działają trochę lepiej z czcionkami proporcjonalnymi:

• „słowa” są łatwiejsze do odczytania - wyskakują na ciebie błędy ortograficzne (np. niepoprawna pisownia zmiennej).
• Czuję się lepiej, używając dłuższych, bardziej opisowych nazw zmiennych (może dlatego, że skanują lepiej, może dlatego, że rozmiar tekstu w poziomie jest skompresowany)
• Taki kod wydaje się nieco łatwiejszy do odczytania . Mojemu mózgowi łatwiej jest „oznaczyć” każde słowo i zrozumieć jego znaczenie. Chociaż, ponieważ znaki interpunkcyjne są trudniejsze do odczytania, nadal jest to trudne - ale może to się zmieni, gdy przyzwyczaisz się do tego trochę czasu

Zaktualizuję tę odpowiedź ponownie jutro (zakładając, że dam radę przez cały taki dzień!)

Lubię zestawiać powiązane warunki, aby było bardziej oczywiste, że są zgrupowane. Na przykład:

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

Czcionki o zmiennej szerokości sprawiają, że jest to trudniejsze.

Ciągle tu widzę dyskusję na temat „wyrównywania kodu” i wcięć. Chciałbym zwrócić uwagę na następujące rzeczy:

• osiem spacji będzie zawsze dwa razy dłuższe niż cztery spacje w dowolnej czcionce.
• dwie zakładki będą zawsze dwa razy dłuższe niż jedna zakładka w dowolnej czcionce.
• każdy identyfikator w jednym wierszu będzie zawsze miał taką samą szerokość w następnym wierszu… dowolną czcionką!
• Oczywiście, jeśli twoi koledzy z drużyny używają stałej odległości, a ty nie, będzie to wyglądać inaczej ... ale powinieneś coś ujednolicić - cokolwiek to jest - i jeśli to prawda, to będzie wyglądać tak samo dla wszystkich. ..w DOWOLNEJ czcionce! Dla śmiechu możesz też spróbować utrzymać wszystkich w stałej pozycji i dać połowie z nich panoramiczne monitory ... zobacz, jak to idzie.
• Jeśli robisz cokolwiek, co polega na ustawianiu kodu w oparciu o kolumnową pozycję tych znaków na ekranie, a nie zakres identyfikatorów, których używasz, zakładam, że to, co robisz, to hack. Identyfikatory nigdy nie powinny być ograniczone do określonej liczby znaków kosztem jakości ich nazw. Poza tym ... nadal nie rysujesz pól ASCII z gwiazdkami w celu umieszczenia komentarzy w swoim kodzie, prawda?

Więc rysując to wszystko razem, jeśli zaczniesz każdy wiersz w tym samym miejscu, a spójne odstępy będą miały tę samą szerokość, a identyfikatory nie zmieniają spontanicznie szerokości w każdym wierszu, wtedy twój kod faktycznie BĘDZIE wyrównany! ... aż coś się zmieni.

na przykład:

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 (); //o nie! źle wyrównany!
• identifier.Method (). Sumthing.YouGetThePoint; //...ale kogo to obchodzi? mają różne właściwości!

Jedyną kwestią, do której przyznaję, jest to, że znaki niealfanumeryczne zazwyczaj nie są zbyt szerokie; obejmują one) (] [} {,: | "; ',`! i. Można to jednak naprawić w edytorze czcionek ... po prostu rozszerzając je. To nie jest problem nieodłączny od braku stałej szerokości; Nie było na to dużego popytu, więc nie zostało to jeszcze zrobione.

Podsumowując, osobiste preferencje są w porządku, ale myślę, że nie ma praktycznego powodu, aby preferować monospace od non-monospace. Podoba ci się ten wygląd? Jasne, wykonuj monospace. Chcesz, aby więcej rzeczy zmieściło się na ekranie? Nie mono. Ale sposób, w jaki ludzie traktują niemonoprzestrzeń jak herezję, jest nieco przesadzony.

Zaciekawił mnie ten wątek, ponieważ wiele argumentów za czcionkami o stałej szerokości można naprawdę łatwo obalić za pomocą pewnych poprawek. Więc przerzuciłem IDE na Calibri (ponieważ ma ładną, okrągłą twarz i jest zoptymalizowany pod kątem czytelności na ekranach dla UI - idealne). Teraz oczywiście muszę używać tabulatorów zamiast spacji do wcięć (ignorując wszystkie problemy), a szerokość 4 spacji wyraźnie nie jest wystarczająca, więc przełączyłem się na 10.

Teraz wygląda całkiem nieźle. Jest jednak kilka oczywistych problemów, które mogę zauważyć. Więcej może pojawić się później, po tym, jak przez jakiś czas przetestowałem te ustawienia.

• Jak już wspomniano, niektóre znaki (zwłaszcza nawiasy, średniki) wyglądają na zbyt cienkie. Chcę to w postaci ciągłego tekstu, ale nie w kodzie źródłowym. Myślę, że to będzie największy problem.

• Symbole nie są dobrze dopasowane. Jako przykład rozważ następujący kod C #:

  var expr = x => x + 1;
  

  Strzałka ( =>) wygląda jak jednostka w przypadku dowolnej czcionki o stałej szerokości. Wygląda jak dwa sąsiadujące ze sobą znaki w innych czcionkach. To samo dotyczy operatorów takich jak >>itp.

• Przestrzenie wyglądają na małe. Energicznie rozmieszczam kody źródłowe, aby zwiększyć czytelność. Przychodzi to do niczego przy zmianie na czcionkę proporcjonalną. Gdybym mógł kontrolować szerokość przestrzeni, to zdecydowanie by pomogło.

• Wcięcia zależne od kontekstu są całkowicie zepsute: w niektórych kontekstach wcięcie określonej liczby zakładek nie wystarczy. Weź wyrażenia LINQ, które mogą być wcięte w następujący sposób:

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

  Po prostu nie możesz tego zrobić za pomocą proporcjonalnej czcionki.

Podsumowując, postacie są zbyt wąskie. Ponownie, dodatkowe odstępy między literami mogą pomóc i jest to zdecydowanie konieczne w przypadku interpunkcji. Mam jednak wrażenie, że wszystkie te poprawki, aby czcionki proporcjonalne były bardziej czytelne, po prostu emulowałyby naturalnie to, co czcionki o stałej szerokości. Z pewnością dotyczy to wszystkich wspomnianych do tej pory punktów.

Używam programu Comic Sans MS, który wygląda całkiem rozsądnie jako małe rozmiary (zaczyna wyglądać „żartobliwie” przy rozmiarach nagłówka). Nie męczy oczu, ale tekst jest wystarczająco mały, aby w oknie tekstowym była widoczna rozsądna ilość kodu, przy otwartych kilku zadokowanych panelach VS.

Możesz mieć panel Eksplorator rozwiązań i nadal mieć 100 kolumn tekstu czytelnych bez przewijania w poziomie. Co więcej, mogę mieć panel DXCore Documentor (wyświetlający sformatowane pliki XMLDOC) otwarty na tyle szeroko, aby móc go czytać, a jednocześnie nadal widzieć wystarczającą ilość tekstu, aby dokumentować XMLdocs.

Jeśli pracujesz w zespole, czcionki o mono-odstępach zapewniają, że kod jest przejrzysty i prawidłowo ułożony dla wszystkich, niezależnie od czcionki o pojedynczej rozstawie, której wolą używać.

Twój kod może wydawać się przejrzysty, gdy używasz czcionki o zmiennej szerokości, ale jest mało prawdopodobne, aby wyglądał tak samo, jeśli otworzy go użytkownik czcionki z mono-odstępami.

Wystarczy kilka godzin, aby dowiedzieć się, dlaczego wyszukiwanie nie znajduje czegoś, ponieważ masz 2 spacje zamiast 1 w dosłownym, aby zdać sobie sprawę, że powinieneś użyć czcionek Monospace. Przydarzyło mi się to raz, kiedy próbowałem naprawić agenta Lotus Notes, gdy projektant nie używał czcionki o stałej szerokości. Dopiero gdy wkleiłem kod do CodeWright, aby go wydrukować, było oczywiste, na czym polega problem.

Czcionki o stałej szerokości znacznie ułatwiają wyrównywanie kodu.

Jest to szczególnie ważne podczas pracy z zespołem; każdy w zespole może używać różnych czcionek i jeśli wszystkie są o stałej szerokości, wszystko się ułoży. Podobnie, jeśli jedna osoba używa wielu różnych narzędzi programistycznych, wszystko będzie się zgadzać, jeśli wszystkie są o stałej szerokości. Gdyby nie wszystkie były o stałej szerokości, musiałbyś upewnić się, że wszystkie używają tej samej czcionki, a jeśli tworzysz na dwóch platformach, może to być trudne.

W rzeczywistości niektóre narzędzia programistyczne obsługują tylko czcionki o stałej szerokości.

Innym powodem jest to, że czcionki o stałej szerokości mają zwykle bardziej wyraźne znaki. Porównaj lIiO0 z lIiO0, a zobaczysz, o co mi chodzi. Ułatwiają również liczenie białych znaków.

Podejrzewam, że czcionki o stałej szerokości były preferencjami programistów jako przeniesienie z dni opartych na DOS-ie.

Z drugiej strony, ja sam wypróbowałem Verdana i kilka innych zalecanych czcionek proporcjonalnych, ale nie mogłem sobie poradzić ze zmianą. Moje oko jest zbyt dobrze wyszkolone na monospace. Języki obfitujące w symbole, takie jak: C / C ++, C #, Perl itp., Wyglądają dla mnie zbyt różne. Umieszczenie symboli sprawia, że ​​kod wygląda zupełnie inaczej.

Z natury kodu, a nie zwykłego języka, ładniej jest mieć go poprawnie ułożonym. Ponadto podczas edycji kodu czasami chcesz zablokować zaznaczanie, kopiowanie i wklejanie bloków. W programie Visual Studio można wybrać blok za pomocą klawisza ALT podczas wybierania myszy. Może być inaczej w różnych edytorach, ale zawsze uważałem, że ta opcja w edytorze jest w niektórych przypadkach bardzo ważna i nie działałaby zbyt dobrze, chyba że używasz czcionki o pojedynczych odstępach.

Osobiście uważam, że czcionki o pojedynczych odstępach są łatwiejsze do odczytania w edytorach kodu. Oczywiście jestem prawie ślepy. To może mieć znaczenie. Obecnie używam czcionki Consolas w 15 punktach na ciemnym tle z kontrastowymi literami.

Używanie spacji do wcięć byłoby problemem, gdybyś wszedł głębiej niż jeden poziom.

Głównie do celów wyrównywania (na przykład, gdy deklaracje parametrów funkcji obejmują wiele wierszy i chcesz je wyrównać, wstawiać komentarze itp.).

Myślę, że podobnie jak w przypadku znaków tabulacji, czynnikiem komplikującym jest sytuacja, gdy coś jest wcięte w celu wyrównania, a ktoś inny ma inne preferencje. Rzeczy się nie wyrównują.