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

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

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

Ответ 1

В моноширинном шрифте:

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

например:

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" Это был большой спрос на него, и поэтому он еще не выполнен.

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

Ответ 5

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

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

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

    var expr = x => x + 1;
    

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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