Я видел пару тем о шрифтах на SO, и кажется, что большинство людей используют моноширинные шрифты для задач программирования. Я использую Verdana для программирования в течение нескольких лет, и мне очень нравится улучшенная читаемость, не пропуская ничего, связанного с моноширинами.
Почему вы используете моноширинный шрифт?
В моноширинном шрифте:
Il 0OРаньше я даже не рассматривал кодирование пропорциональным шрифтом. Так что в интересах науки я просто переключил своего редактора, чтобы попробовать.
Вот несколько наблюдений после исправления пары простых тикетов:
! в if (!foo). (если (!foo), см.!){}[]() против {}[]())$@% против $@%)'"!;:,. против '"!;:,.)0Oo iIl против 00o iIl)Однако есть и положительные моменты. По общему признанию, я использую его совсем недавно, но, безусловно, есть некоторые аспекты, которые работают немного лучше с пропорциональными шрифтами:
Завтра я снова обновлю этот ответ (при условии, что смогу продержаться целый день!)
Мне нравится выстраивать связанные условные предложения, чтобы было более очевидно, что они сгруппированы. Например:
if ((var1 == FOO) && ((var2 == BAR) ||
(var2 == FOOBAR)))
Шрифты переменной ширины усложняют задачу.
Одна вещь, которую я постоянно вижу здесь, — это обсуждение «выравнивания кода» и отступов. Я хотел бы отметить следующие вещи:
Итак, собрав все это вместе, если вы начинаете каждую строку в одном и том же месте, и постоянный интервал имеет одинаковую ширину, а идентификаторы не меняют ширину спонтанно в каждой строке, тогда ваш код действительно выстроится! ... пока что-то не изменилось.
Например:
identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //how lined up and pretty!
identifier.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) достаточно широко, чтобы читать, но при этом иметь возможность видеть достаточно текста для документирования документов XML.
Если вы работаете в команде, моноширинные шрифты гарантируют, что код будет четким и правильным для всех, какой моноширинный шрифт они предпочитают использовать.
Ваш код может показаться вам понятным при использовании шрифта переменной ширины, но вряд ли он будет выглядеть так же, если его откроет пользователь с моноширинным шрифтом.
Все, что требуется, — это несколько часов попыток понять, почему поиск ничего не находит, потому что у вас есть 2 пробела вместо 1 в вашем литерале, чтобы понять, что вы должны использовать моноширинные шрифты. Это случилось со мной однажды, когда я пытался исправить агент Lotus Notes, когда дизайнер не использовал моноширинный шрифт. Только когда я вставил код в CodeWright, чтобы распечатать его, стало очевидно, в чем проблема.
Моноширинные шрифты значительно упрощают выравнивание кода.
Это особенно верно при работе с командой; все в команде могут использовать разные шрифты, и пока они все моноширинные, все будет выравниваться. Точно так же, если один человек использует множество различных инструментов разработки, все будет выстраиваться, если все они будут моноширинными. Если бы они не были все моноширинными, вам пришлось бы убедиться, что все они используют один и тот же шрифт, а если вы разрабатываете на двух платформах, это может быть сложно.
Фактически, некоторые средства разработки поддерживают только моноширинные шрифты.
Другая причина заключается в том, что моноширинные шрифты имеют более четкие символы. Сравните lIiO0 с lIiO0, и вы поймете, что я имею в виду. Они также значительно облегчают подсчет пробелов.
Я подозреваю, что моноширинные шрифты были предпочтением программистов как пережиток текстовых дней DOS.
С другой стороны, я сам пробовал Verdana и пару других рекомендуемых пропорциональных шрифтов, но не смог справиться с изменением. Мой глаз слишком хорошо натренирован для моноширинного изображения. Языки, насыщенные символами, такие как: C/C++, C#, Perl и т. д., для меня выглядят слишком по-другому. Размещение символов делает код совершенно другим.
По характеру кода, а не обычного языка, лучше, чтобы он был правильно выстроен. Кроме того, при редактировании кода иногда требуется заблокировать выбор, копирование и вставку блока. В Visual Studio вы можете сделать выбор блока, используя клавишу ALT во время выбора мышью. Это может быть по-разному в разных редакторах, но я всегда находил этот параметр в редакторе очень важным в некоторых случаях, и он не будет работать очень хорошо, если вы не используете моноширинный шрифт.
Лично я считаю, что моноширинные шрифты легче читать в редакторах кода. Я, конечно, почти слепой. Это может иметь значение. В настоящее время я запускаю шрифт consolas размером 15 пунктов с темным фоном и высококонтрастными буквами.
Использование пробелов для отступов станет проблемой, если вы окажетесь глубже одного уровня.
В основном для целей выравнивания (например, когда объявления параметров функции занимают несколько строк, и вы хотите выровнять их или выровнять комментарии и т. д.).
Я думаю, как и в случае с символами табуляции, усложняющим фактором является то, что что-то имеет отступ для целей выравнивания, а у кого-то другие предпочтения. Вещи смещаются.
