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

Question

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

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

Answer 1

В моноширинный шрифт:

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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

У вас может быть панель «Проводник решений» и все еще есть 100 столбцов текста, читаемых без горизонтальной прокрутки. Moveover, я могу открыть панель DXCore Documentor (отображать отформатированные XMLDOC), чтобы они были достаточно широкими, чтобы читать, все еще имея возможность видеть достаточно текста для документирования XMLdocs.

Answer 10

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

Answer 11

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

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

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

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

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

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

Answer 12

Мне стало любопытно эту тему, потому что многие аргументы для моноширинных шрифтов действительно могут быть опровергнуты с некоторой настройкой. Поэтому я переключил свою 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); 
  

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

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

Answer 13

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

Answer 14

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

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

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

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

Answer 15

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

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

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

, например:

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(); //о нет! криво!
• identifier.Method(). Sumthing.YouGetThePoint; //...но кого это волнует? они разные свойства!

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

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