Зачем использовать моноширинные шрифты в вашей среде IDE? [закрыто]

Я видел пару тем о шрифтах на SO, и кажется, что большинство людей используют моноширинные шрифты для задач программирования. Я использую Verdana для программирования пару лет, и мне очень нравится улучшенная читаемость, без упущения ничего, связанного с моноширинным пространством.

Почему вы используете моноширинный шрифт?

Моноширинным шрифтом:

• Строковые литералы одинаковой длины выглядят одинаково.
• Легче увидеть тонкие знаки препинания, например: () {}
• Похожие персонажи выглядят более разными: Il 0O vs Il 0O
• Вы знаете, будет ли строка переноситься на окно шириной X символов. Это означает, что ваша команда может стандартизировать, скажем, 100 строк символов, и строка всегда будет выглядеть как строка.

Я никогда раньше даже не задумывался о кодировании пропорциональным шрифтом. Так что в интересах науки я просто сменил своего редактора, чтобы попробовать.

Вот несколько наблюдений после исправления пары простых билетов:

• Код кажется чрезвычайно плотным. Большая часть моего кода содержит около 80 столбцов, редко более 100. Пропорциональные шрифты сжимают его до крошечной полоски в левой части моего редактора. Может быть полезно, если у вас мало места на экране, но он кажется излишне компактным.
• «Текстура» кода теряется. Трудно сказать, на какую структуру я смотрю - это просто большой кусок текста, который нужно читать почти посимвольно.
• Это очень легко пропустить !оператор в if (!foo). (если (! foo), смотри!)
• Знаки пунктуации очень плохо определены. Многих сложно отличить друг от друга ( {}[]()vs {} [] ())
• Некоторые символы пунктуации намного крупнее других, что означает выделение там, где они не предназначены ( $@%против $ @%)
• Некоторые символы очень узкие, и их очень сложно идентифицировать ( '"!;:,.vs '"!;:,.)
• Некоторые цифры и буквы очень похожи (по 0Oo iIlсравнению с 0Oo iIl)
• Я очень полагаюсь на подсветку синтаксиса, без нее почти невозможно делать такие вещи, как подтверждение баланса кавычек и т. Д.
• Выравнивание (кроме простых отступов) полностью нарушено. Вы можете сортировать его, добавив лишние пробелы, но из-за пропорционального характера шрифтов строки могут не совпадать точно - код выглядит более запутанным .
• Регулярные выражения ... интересны!

Но есть и положительные моменты. По общему признанию, я использую его совсем недавно, но, безусловно, есть некоторые аспекты, которые немного лучше работают с пропорциональными шрифтами:

• "слова" легче читать - вам бросаются в глаза орфографические ошибки (например, неправильное написание переменной).
• Мне лучше использовать более длинные и описательные имена переменных (возможно, потому, что они лучше сканируют, может быть, потому, что горизонтальный размер текста сжимается)
• Кажется, такой код немного легче читать . Моему мозгу легче «токенизировать» каждое слово и понимать его значение. Хотя из-за того, что знаки препинания сложнее читать, это все еще сложно - но, возможно, это изменится, если немного времени, чтобы привыкнуть к этому.

Я обновлю этот ответ завтра снова (при условии, что я смогу прожить так целый день!)

Мне нравится выстраивать связанные условные выражения, чтобы было более очевидно, что они сгруппированы. Например:

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

Шрифты переменной ширины усложняют задачу.

Одна вещь, которую я продолжаю видеть здесь, - это обсуждение «выравнивания кода» и отступов. Хочу отметить следующее:

• восемь пробелов всегда будут вдвое длиннее четырех пробелов в любом шрифте.
• две вкладки всегда будут вдвое длиннее одной вкладки любым шрифтом.
• любой идентификатор в одной строке всегда будет такой же ширины в следующей строке ... любым шрифтом!
• Конечно, если ваши товарищи по команде используют моноширинный режим, а вы нет, это будет выглядеть по-другому ... но вы должны стандартизировать что-то - что бы это ни было - и если это правда, то это будет выглядеть одинаково для всех. ..в ЛЮБОМ шрифте! Для смеха вы также можете попробовать оставить всех в моноширинном режиме и дать половине из них широкоэкранные мониторы ... посмотрим, как это получится.
• Если вы делаете что-либо, основанное на выстраивании кода на основе столбца этих символов на экране, а не на объеме используемых вами идентификаторов, я утверждаю, что то, что вы делаете, является взломом. Идентификаторы никогда не должны ограничиваться определенным количеством символов за счет качества их имен. Помимо этого ... вы все еще не рисуете блоки ASCII со звездочками для комментариев в своем коде, не так ли?

Итак, если собрать все это вместе, если вы начинаете каждую строку в одном и том же месте, а постоянный интервал имеет одинаковую ширину, а идентификаторы не меняют ширину спонтанно на каждой строке, тогда ваш код действительно будет выстраиваться в линию! ... пока что-то не изменится.

например:

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

• идентификатор.Метод (). Свойство.ToString ();
• идентификатор.Method (). OtherGuy.ToString (); //о нет! смещено!
• идентификатор.Method (). Sumthing.YouGetThePoint; //...но кого это волнует? они разные свойства!

Единственное, что я признаю, это то, что не буквенно-цифровые символы обычно не очень широкие; к ним относятся) (] [} {,: | "; ',`! и. Это, однако, можно исправить в редакторе шрифтов ... просто сделав их шире. Это не проблема, присущая немоноширинным шрифтам; там просто есть На него не было большого спроса, так что это еще не сделано.

Таким образом, личные предпочтения - это хорошо, но я думаю, что нет особых практических причин предпочитать моноширинный режим немоноширинному. Вам нравится, как это выглядит? Конечно, сделайте моноширинный. Хотите, чтобы на экране поместилось больше информации? Не моно. Но то, как люди относятся к немонопространству как к ереси, немного преувеличено.

Мне стало любопытно в этой теме, потому что многие аргументы в пользу моноширинных шрифтов действительно можно легко опровергнуть с помощью некоторых настроек. Поэтому я переключил свою IDE на Calibri (потому что у нее красивое круглое лицо и она оптимизирована для удобочитаемости на экранах для пользовательского интерфейса - идеально). Теперь мне, очевидно, приходится использовать табуляцию вместо пробелов для отступов (игнорируя все проблемы), а ширины 4 пробелов явно недостаточно, поэтому я переключился на 10.

Теперь выглядит неплохо. Однако есть несколько очевидных проблем, которые я мог заметить. Больше может появиться позже, после того как я некоторое время протестирую эти настройки.

• Как уже упоминалось, некоторые символы (особенно круглые скобки, точки с запятой) выглядят слишком тонкими. Я хочу, чтобы это было непрерывным текстом, но не в исходном коде. Думаю, это будет самая большая проблема.

• Символы не совпадают. В качестве примера рассмотрим следующий код C #:

  var expr = x => x + 1;
  

  Стрелка ( =>) выглядит как единое целое в любом моноширинном шрифте. Это похоже на два соседних символа в других шрифтах. То же самое и с операторами вроде >>т. Д.

• Пространства выглядят крошечными. Я активно размещаю свои исходные коды, чтобы улучшить читаемость. Это сходит на нет при переходе на пропорциональный шрифт. Если бы я мог контролировать ширину пробелов, это определенно помогло бы.

• Контекстно-зависимые отступы полностью нарушены: в некоторых контекстах недостаточно отступа для фиксированного количества вкладок. Возьмите выражения LINQ, которые могут иметь следующий отступ:

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

  Вы просто не можете этого сделать с пропорциональным шрифтом.

В общем, персонажи слишком узкие. Опять же, дополнительный межбуквенный интервал может помочь, и это определенно необходимо в случае пунктуации. Однако у меня такое чувство, что вся эта настройка, чтобы сделать пропорциональные шрифты более читабельными, просто имитировала бы естественные моноширинные шрифты. Это, безусловно, верно для всех упомянутых выше моментов.

Я использую Comic Sans MS, который выглядит вполне разумно для небольших кеглей (это только начинает выглядеть "шуткой" при размере заголовков). Это легко для глаз, но при этом сохраняет текст достаточно мелким, чтобы в текстовом окне было видно разумное количество кода при открытых пристыкованных панелях VS.

Вы можете отключить панель обозревателя решений и по-прежнему иметь 100 столбцов текста, читаемых без горизонтальной прокрутки. Кроме того, я могу открыть панель DXCore Documentor (отображающую отформатированные XMLDOC) достаточно широко, чтобы ее можно было читать, но при этом я могу видеть достаточно текста для документирования XMLdocs.

Если вы работаете в команде, то однотонные шрифты гарантируют, что код ясен и правильно разложен для всех, независимо от того, какой монотонный шрифт они предпочитают использовать.

Ваш код может выглядеть понятным при использовании шрифта переменной ширины, но вряд ли он будет выглядеть так же, если пользователь шрифта с одинарным интервалом откроет его.

Все, что нужно, - это несколько часов попытаться выяснить, почему поиск не находит чего-то, потому что у вас есть 2 пробела вместо 1 в вашем литерале, чтобы понять, что вам следует использовать моноширинные шрифты. Это случилось со мной однажды, когда я пытался исправить агент Lotus Notes, когда дизайнер не использовал моноширинный шрифт. Только когда я вставил код в CodeWright, чтобы распечатать его, стало очевидно, в чем проблема.

Моноширинные шрифты значительно упрощают выстраивание кода.

Это особенно актуально при работе в команде; каждый в команде может использовать разные шрифты, и пока все они моноширинные, все будет выровнено. Точно так же, если один человек использует много разных инструментов разработки, все выровняется, если все они моноширинные. Если бы не все они были моноширинными, вам нужно было бы убедиться, что все они используют один и тот же шрифт, а если вы разрабатываете на двух платформах, это может быть сложно.

Фактически, некоторые инструменты разработки поддерживают только моноширинные шрифты.

Другая причина заключается в том, что в моноширинных шрифтах характерны более четкие символы. Сравните lIiO0 с lIiO0, и вы поймете, что я имею в виду. Они также значительно упрощают подсчет пробелов.

Я подозреваю, что моноширинные шрифты были предпочтением программистов, поскольку они были перенесены со времен текстовой DOS.

С другой стороны, я сам пробовал Verdana и пару других рекомендуемых пропорциональных шрифтов, но не смог с этим справиться. Мой глаз слишком хорошо натренирован для моноширинного пространства. Языки, в которых много символов, например: C / C ++, C #, Perl и т. Д., Кажутся мне слишком разными. Размещение символов делает код совершенно другим.

По характеру кода, а не обычного языка, лучше правильно выстроить его. Кроме того, при редактировании кода иногда требуется заблокировать выделение, заблокировать копирование и заблокировать вставку. В Visual Studio вы можете выбрать блок, используя клавишу ALT при выборе мыши. Он может отличаться в разных редакторах, но я всегда считал, что этот параметр в редакторе очень важен в некоторых случаях, и он не будет работать очень хорошо, если вы не используете шрифт с одним интервалом.

Лично мне кажется, что монотонные шрифты легче читать в редакторах кода. Конечно, я почти слепой. Это может иметь значение. В настоящее время я использую шрифт consolas размером 15 пунктов на темном фоне с высококонтрастными буквами.

Использование пробелов для отступов станет проблемой, если вы перейдете на глубину более одного уровня.

В основном для целей выравнивания (например, когда объявления параметров функции охватывают несколько строк, и вы хотите выровнять их, или выровнять комментарии и т. Д.).

Я думаю, что, как и в случае с символами табуляции, усложняющий фактор - это когда что-то имеет отступ для целей выравнивания, а у кого-то другие предпочтения. Вещи не совпадают.