Зачем использовать моноширинные шрифты в вашей среде IDE?
Я видел пару тем о шрифтах на SO, и кажется, что большинство людей используют моноширинные шрифты для задач программирования. Я использую Verdana для программирования в течение нескольких лет, и мне очень нравится улучшенная читаемость, без упущения ничего, связанного с моноширинным пространством.
Почему вы используете моноширинный шрифт?
Лично мне нравится использовать для себя Сан-Франциско (lowendmac.com/backnforth/2k0601.html) ... :)
Я думаю, что Trim идет даже дальше, чем Verdana, в обеспечении читабельности кода. (code.google.com/p/i3project/wiki/Fonts)
По крайней мере, я не единственный еретик, который использует Вердану. :)
Откройте это заново. Знание правильного инструмента / техники для работы и причин для этого определенно стоит обсудить.
Я единственный, кто использует Comic Sans для программирования. :)
Ответы 15
Моноширинным шрифтом:
- Строковые литералы одинаковой длины выглядят одинаково.
- Легче увидеть тонкие знаки препинания, например: () {}
- Похожие персонажи выглядят более разными: Il 0O vs
Il 0O - Вы знаете, будет ли строка переноситься на окно шириной X символов. Это означает, что ваша команда может стандартизировать, скажем, 100 строк символов, и строка всегда будет выглядеть как строка.
Второй и третий пункты действительно не так уж специфичны для моноширинных. Это больше вопрос о том, какой шрифт вы используете, а не о том, моноширинный он или нет. Verdana хорошо справляется с обоими пунктами (лучше, чем большинство моноширинных шрифтов, imo), поэтому я использую ее.
Чтобы исправить каждый из них: Эквивалентные строки выглядят одинаковой ширины, и я задаюсь вопросом, почему вы заботитесь о строках, которые отличаются друг от друга и имеют только одну длину. Non-monowidth не означает, что символы пунктуации должны быть тонкими; вам следует использовать другой немоно шрифт. «Подобные» символы не обязательно выглядят по-разному в моноширинном пространстве; SimHei, например, имеет идентичные O и 0. Это свойство шрифта, а не ширина. Наконец, если ваша команда действительно стандартизирует, тогда вы можете выбрать немоно и стандартизировать на «не позволяйте этому стекать с экрана».
Использование пробелов для отступов станет проблемой, если вы перейдете на глубину более одного уровня.
Собственно, любая достойная IDE должна с этим справиться.
Это только еще одна причина использовать вкладки для отступов (это причина, по которой добрый Господь дал вкладки в первую очередь)
+1 за вкладки (теперь о местонахождении этих дебатов ...)
Лично я считаю, что монотонные шрифты легче читать в редакторах кода. Конечно, я почти слепой. Это может иметь значение. В настоящее время я использую шрифт consolas размером 15 пунктов с темным фоном с высококонтрастными буквами.
На самом деле Consolas - это шрифт с одинарным интервалом. Причем очень хороший. Я тоже им пользуюсь.
+1 для Consolas и Inconsolata на Mac
@ Джо Мюллер - понятия не имею, как я это написал. Я имею ввиду противоположное тому, что я написал. Позвольте мне отредактировать это .... хорошо. :)
Я бы порекомендовал вам попытаться найти хороший немоноширинный шрифт, оптимизированный для кода, и переключиться на светлый фон, прежде чем вы полностью ослепнете, без обид, просто то, что мне подсказывает мой опыт.
Мне нравится выстраивать связанные условные выражения, чтобы было более очевидно, что они сгруппированы. Например:
if ((var1 == FOO) && ((var2 == BAR) ||
(var2 == FOOBAR)))
Шрифты переменной ширины усложняют эту задачу.
Действительный пункт. Но при вертикальном расположении вещей возникает проблема: что, если вам нужно что-то изменить в этом операторе if? Вероятно, вам нужно будет все выровнять.
@Calmarius: "сделать его читабельным" - часть моего дневного программирования, я делаю это неосознанно. Если вы приложите усилия для изменения кода, вам также следует приложить усилия для снижения затрат на обслуживание.
Лучший способ добиться этого - эластичные петлицы, даже если вы придерживаетесь моноширинного шрифта. Не то чтобы это практичная альтернатива в редакторах ток ...
@romkyns: эластичные табуляции достаточно умны, чтобы выровнять круглую скобку с другой скобкой?
@endolith Ну, они определенно умнее, чем пробелы ... :) Вам все равно нужно решить, что вы хотите согласовать с чем; большое преимущество в том, что как только вы это сделаете, все останется на одном уровне, даже если другие вещи изменятся.
@romkyns: Как бы вы выстроили круглые скобки в этом случае?
@endolith Вы должны вставить табуляцию между двумя круглыми скобками в первой строке и табуляцию перед открывающей скобкой во второй строке. Теперь это добавило бы дополнительное пространство между двумя скобками в строке 1 в ванильной реализации, но вы бы получили выравнивание, которое сохраняется при редактировании, что для меня звучит как очень стоящий компромисс. На самом деле, я бы даже добавил табуляцию после закрывающей круглой скобки в обеих строках. См. снимок экрана, во всей красе шрифта переменной ширины, или попробуй сам.
Я подозреваю, что моноширинные шрифты были предпочтением программистов, поскольку они были перенесены со времен DOS, основанных на тексте.
С другой стороны, я сам пробовал Verdana и пару других рекомендуемых пропорциональных шрифтов, но не смог с этим справиться. Мой глаз слишком хорошо натренирован для моноширинного пространства. Языки, в которых много символов, например: C / C++, C#, Perl и т. д., Кажутся мне слишком разными. Размещение символов делает код совершенно другим.
Кажется, это настоящий ответ, я также думаю, что в основном это связано с привычками / историческими причинами, а все остальное - просто ограничения редактора кода или плохие шрифты.
Я думаю, что, как и в случае с символами табуляции, усложняющий фактор - это когда что-то имеет отступ для целей выравнивания, а у кого-то другие предпочтения. Вещи не совпадают.
По природе кода, а не обычному языку, лучше правильно выстроить его. Кроме того, при редактировании кода иногда требуется заблокировать выбор, заблокировать копирование и заблокировать вставку. В Visual Studio вы можете выбрать блок, используя клавишу ALT при выборе мыши. В разных редакторах он может отличаться, но я всегда считал, что этот параметр в редакторе очень важен в некоторых случаях, и он не будет работать очень хорошо, если вы не используете шрифт с одинарным интервалом.
Теперь есть новые комбинации клавиш, которых я раньше не знал. Ваше здоровье.
Если вы работаете в команде, то однотонные шрифты гарантируют, что код ясен и правильно разложен для всех, независимо от того, какой монотонный шрифт они предпочитают использовать.
Ваш код может выглядеть понятным при использовании шрифта переменной ширины, но вряд ли он будет выглядеть так же, если пользователь шрифта с одинарным интервалом откроет его.
Я использую Comic Sans MS, который выглядит вполне разумно для небольших кеглей (это только начинает выглядеть "шуткой" при размере заголовков). Это легко для глаз, но при этом сохраняйте достаточно мелкий текст, чтобы в текстовом окне был виден разумный объем кода, при этом некоторые из закрепленных панелей VS открыты.
Вы можете отключить панель обозревателя решений и по-прежнему иметь 100 столбцов текста, читаемых без горизонтальной прокрутки. Кроме того, я могу открыть панель DXCore Documentor (отображающую отформатированные XMLDOC) достаточно широко, чтобы ее можно было читать, но при этом я все еще могу видеть достаточно текста для документирования XMLdocs.
О чувак. Почему? Я бы хотел услышать ваше оправдание!
Использование comic sans для что-нибудь :)
Мое оправдание - это остальная часть сообщения.
Ваше оправдание - "это мало"? Из всех особенностей Comic Sans, его «малость» редко бывает предпочтительнее других шрифтов. К тому же из-за этого ты выглядишь так, будто тебе 12. Если бы я работал с тобой, я бы точно посмеялся над тобой за это сейчас :)
@Dan, нет, это удобочитаемый, КОГДА он маленький, что является частым приоритетом при выборе шрифта. А смеясь над человеком над выбором шрифта, вы выглядите на 12.
Полностью скумбрия - я только что попробовал, и это работает. Джеймс, вероятно, обнаружил единственную оставшуюся причину существования Comic Sans - его хорошо читаем до 7pt. В следующий раз, когда мне придется реорганизовать чей-то кодовый беспорядок с методами тысячи строк, я буду использовать этот шрифт.
Это вполне может быть читаемым, но я бы все равно не стал признавать это публично :)
Теперь ЭТО был шокирующий опыт! Я все еще не уверен в использовании опорных шрифтов, но Comic Sans действительно можно использовать. Я знаю, что это глупый и оскорбительный шрифт, который вызывает случайный визуальный ужас и никогда не должен был появиться. Но он работает в малых масштабах, и его можно использовать. Остальное просто снобизм. Спасибо, Джеймс!
Я использую MS Sans Serif (еще один немоноширинный), и хотя он уменьшается только до 9pt, он умещается в том же количестве строк на экране, по 57 строк для каждого шрифта, несмотря на то, что у него более высокие символы - меньше внутристрочного пространства . Должен признаться, я бы никогда не уделил этому времени суток, но все выглядело неплохо.
проголосовали за то, что вы используете comic sans. это наверняка идет против течения
В основном для целей выравнивания (например, когда объявления параметров функций охватывают несколько строк, и вы хотите выровнять их, или выровнять комментарии и т. д.).
Я никогда раньше даже не думал о кодировании пропорциональным шрифтом. Так что в интересах науки я просто сменил своего редактора, чтобы попробовать.
Вот несколько наблюдений после исправления пары простых тикетов:
- Код кажется чрезвычайно плотным. Большая часть моего кода состоит из примерно 80 столбцов, редко более 100. Пропорциональные шрифты сжимают его до крошечной полоски в левой части моего редактора. Может быть полезно, если у вас мало места на экране, но он кажется излишне компактным.
- «Текстура» кода теряется. Трудно сказать, на какую структуру я смотрю - это просто большой кусок текста, который нужно читать почти посимвольно.
- очень легко пропустить оператор
!вif (!foo). (если (! foo), смотри!) - Знаки пунктуации очень плохо определены. Многие из них сложно отличить друг от друга (
{}[]()vs {} [] ()) - Некоторые знаки препинания намного крупнее других, что подразумевает выделение там, где он не предназначен (
$@%против $ @%) - Некоторые символы очень узкие, и их очень трудно идентифицировать (
'"!;:,.vs '"!;:,.) - Некоторые цифры и буквы очень похожи (
0Oo iIlпротив 0Oo iIl) - Я очень сильно полагаюсь на подсветку синтаксиса, без нее почти невозможно делать такие вещи, как подтверждение баланса кавычек и т. д.
- Выравнивание (кроме простого отступа) полностью нарушено. Вы можете сортировать его, добавив лишние пробелы, но из-за пропорционального характера шрифтов линии могут не совпадать точно - код выглядит запутаннее.
- Регулярные выражения ... интересны!
Но есть у являются и положительные моменты. По общему признанию, я использую его совсем недавно, но, безусловно, есть некоторые аспекты, которые немного лучше работают с пропорциональными шрифтами:
- «слова» легче читать - вам бросаются в глаза орфографические ошибки (например, неправильное написание переменной).
- Мне удобнее использовать более длинные и описательные имена переменных (возможно, потому, что они лучше сканируют, может быть, потому, что горизонтальный размер текста сжимается)
- Такой код читать кажется немного проще. Моему мозгу легче «токенизировать» каждое слово и понимать его значение. Хотя из-за того, что знаки препинания сложнее читать, это все еще сложно - но, возможно, это изменится, если немного времени, чтобы привыкнуть к этому.
Я обновлю этот ответ завтра снова (при условии, что я смогу прожить так целый день!)
Хорошая работа! Однако мне интересно, какой шрифт вы использовали, поскольку большинство ваших замечаний по поводу слишком похожих персонажей меня совсем не беспокоит.
Я начал с Arial, перешел на Calibri. Я попробовал несколько других, но они тоже оказались лучшими, основываясь на 20 секундах крайне ненаучного поиска в моем списке шрифтов и рекомендации Конрада Рудольфа.
«Я никогда раньше даже не думал о кодировании с использованием пропорционального шрифта. Поэтому в интересах науки я просто переключил свой редактор, чтобы попробовать». Сколько лет вы программировали и привыкли к фиксированной ширине? Здесь у вас есть достойный ответ, но вы не учитываете собственную предвзятость (а это было бы трудно сделать без дополнительной работы), что не очень хорошая наука.
@ Роджер: Возможно, это плохая наука (провести такое исследование было бы почти невозможно и очень дорого!), Но причины вполне правдоподобны. А сломанный отступ - аргумент, который трудно превзойти (в текущих IDE / редакторах; эта проблема решается за счет разумного отступа с использованием позиций табуляции, которые соответствуют семантике).
@Konrad: Не воспринимайте мой предыдущий комментарий как слишком отрицательный (я вижу, теперь вы можете прочитать мой комментарий таким образом; здесь сложно передать тон), ваши впечатления в этом ответе полезны. Это просто казалось неискренним: например, при первом наблюдении, конечно, код кажется плотным, когда у вас есть X годы использования фиксированной ширины и Y минут использования пропорционального.
Что касается отступа, это не проблема. Выравнивание нескольколинии - аргумент, который трудно превзойти с использованием текущих инструментов, но он используется меньше, чем обычный отступ.
Пропорциональный шрифт, разработанный специально для программирования, решит большинство обычных возражений. Есть несколько пропорциональных шрифтов для кодирования на code.google.com/p/i3project/wiki/Fonts
Какой шрифт вы использовали?
слова и орфография не должны быть проблемой, так как в любом случае можно было бы использовать инструменты i18n для манипулирования текстовыми символами ... но я думаю, это помогает?
Меня заинтересовала эта ветка, потому что многие аргументы в пользу моноширинных шрифтов действительно можно легко опровергнуть с помощью некоторых настроек. Поэтому я переключил свою 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);Вы просто не можете этого сделать с пропорциональным шрифтом.
В общем, персонажи слишком узкие. Опять же, дополнительный межбуквенный интервал может помочь, и это определенно необходимо в случае пунктуации. Однако у меня такое чувство, что вся эта настройка, чтобы сделать пропорциональные шрифты более читабельными, просто имитировала бы естественные моноширинные шрифты. Это, безусловно, верно для всех упомянутых выше моментов.
На самом деле Calibri немного лучше, чем Arial (это то, с чем я тестировал), хотя он все еще демонстрирует аналогичные проблемы.
Пробовал несколько шрифтов. Calibri и Lucida Sans Unicode кажутся наиболее вероятными кандидатами. Неслучайно Lucida Sans Unicode (под псевдонимом «Lucida Grande») является шрифтом пользовательского интерфейса OS X.
Да, на самом деле эти двое очень похожи. Calibri выигрывает для меня, так как в нем немного более четкая пунктуация.
Возможно, это только я, но я обнаружил, что интервалы Calibri невероятно непредсказуемы - некоторые пространства кажутся несуществующими, а другие кажутся огромными. Даже не обращая внимания на программирование, я отключил его на каждой машине, которую использую.
@bwerks: что ты имеешь в виду - ты его «отключаешь»? Только не используйте его, если он вам не нравится. Кроме того, когда, кроме программирования, вы используете интервалы? Для форматирования? Не, это смертный грех. Более того, то, что вы наблюдаете, может быть просто следствием плохого алгоритма разрыва строки в Microsoft Word, поскольку интервал Calibri всегда один и тот же: пространство всегда имеет одинаковую ширину. В частности, на него не влияет кернинг.
Пользовательский интерфейс Segoe, кажется, имеет достаточно широкий символ свободного пространства из коробки, хотя кто-то, кого я знаю, просто отредактировал свой любимый шрифт, чтобы сделать пространство шире. Не знал, что это легко сделать.
@romkyns Fontforge очень мощный и, по-видимому, довольно простой в использовании (сам никогда не использовал). На самом деле я считаю, что Comic Sans - это самый читаемый шрифт кода (и я слышал, что есть исследования читабельности, которые показывают, что Comic Sans действительно лучший шрифт просто с точки зрения читаемости). Увы, это еще и некрасиво. Если кто-нибудь когда-либо создавал более красивую альтернативу (и если бы редакторы кода поддерживали пропорциональные шрифты), это сделало бы меня гораздо более склонным к пропорциональным программным шрифтам.
@KonradRudolph Fontforge - единственное известное мне бесплатное программное обеспечение для редактирования шрифтов, но, к сожалению, оно постоянно дает сбой в Windows 7. Я не уверен, можно ли это исправить, очевидно, эта программа была скомпилирована для WinXP или даже Win98.
@KonradRudolph Упс, верните мои слова, они недавно выпустили новую версию, установили ее сейчас, и она не дает сбоев, по крайней мере, до сих пор. Я заинтригован
Все, что нужно, - это несколько часов попытаться выяснить, почему поиск не находит чего-то, потому что у вас есть 2 пробела вместо 1 в вашем литерале, чтобы понять, что вам следует использовать моноширинные шрифты. Это случилось со мной однажды, когда я пытался исправить агент Lotus Notes, когда дизайнер не использовал моноширинный шрифт. Только когда я вставил код в CodeWright, чтобы распечатать его, стало очевидно, в чем проблема.
Ширина пространства постоянна при использовании пропорционального шрифта, не так ли?
Или вы можете использовать пропорциональный шрифт с более широким пространством. Пропорциональность сама по себе не вызывает проблемы, о которой вы говорите.
Моноширинные шрифты значительно упрощают выстраивание кода.
Это особенно актуально при работе в команде; каждый в команде может использовать разные шрифты, и пока они все моноширинные, все будет выровнено. Точно так же, если один человек использует много разных инструментов разработки, все выровняется, если все они моноширинные. Если бы не все они были моноширинными, вам нужно было бы убедиться, что все они используют один и тот же шрифт, а если вы разрабатываете на двух платформах, это может быть сложно.
Фактически, некоторые инструменты разработки поддерживают только моноширинные шрифты.
Другая причина заключается в том, что в моноширинных шрифтах характерны более отчетливые символы. Сравните lIiO0 с lIiO0, и вы поймете, что я имею в виду. Они также значительно упрощают подсчет пробелов.
«все выровняется» - только если ваша команда решила Единую Священную Войну вкладок против пробелов и / или имеет одинаковую настройку ширины вкладок.
Даже если вы используете отступ табуляции, вы все равно должны использовать пробелы для выравнивания после отступа.
Я все время вижу здесь обсуждение «выравнивания кода» и отступов. Хочу отметить следующее:
- восемь пробелов всегда будут вдвое длиннее четырех пробелов в любом шрифте.
- две вкладки всегда будут вдвое длиннее одной вкладки любым шрифтом.
- любой идентификатор в одной строке всегда будет такой же ширины в следующей строке ... любым шрифтом!
- Конечно, если ваши товарищи по команде используют моноширинный режим, а вы нет, это будет выглядеть по-другому ... но вы должны стандартизировать что-то - что бы это ни было - и если это правда, то это будет выглядеть одинаково для всех. ..в ЛЮБОМ шрифте! Для смеха вы также можете попробовать оставить всех в моноширинном режиме и дать половине из них широкоэкранные мониторы ... посмотрим, как это получится.
- Если вы делаете что-либо, основанное на выстраивании кода на основе столбца этих символов на экране, а не на объеме используемых вами идентификаторов, я предполагаю, что то, что вы делаете, является взломом. Идентификаторы никогда не должны ограничиваться определенным количеством символов за счет качества их имен. Кроме того ... вы все еще не рисуете блоки 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; //...но кого это волнует? они разные свойства!
Единственное, что я признаю, это то, что не буквенно-цифровые символы обычно не очень широкие; к ним относятся) (] [} {,: | "; ',`! и. Это, однако, можно исправить в редакторе шрифтов ... просто сделав их шире. Это не проблема, присущая немоноширинным шрифтам; там просто есть На него не было большого спроса, и поэтому это еще не сделано.
Таким образом, личные предпочтения - это хорошо, но я думаю, что практических причин предпочитать моноширинный режим немоноширинному практически нет. Вам нравится, как это выглядит? Конечно, сделайте моноширинный. Вы хотите, чтобы на вашем экране поместилось больше информации? Не моно. Но то, как люди относятся к немонопространству как к ереси, немного преувеличено.
+1, чтобы увидеть больше информации на вашем экране. А коробки ASCII ... ... ну, пустая трата времени.
+1; эти моменты на самом деле трудно оценить, пока кто-то не использует пропорциональный шрифт какое-то время.
+1 за широкое понимание того, что пропорциональные шрифты, разработанные специально для программирования, могут быть созданы и не обязательно должны быть моноширинными. Если бы пропорциональные шрифты были более обычным явлением в программировании, могла бы возникнуть новая культура «типографики программирования». Не так с «ересью».
Я действительно попытался сделать этот пропорциональный программный шрифт - это не так уж и плохо! Редактирование шрифтов - это боль, но вам нужно сделать это только один раз.
Хотел бы я проголосовать за это дважды ... годами безуспешно ломал голову над этими же пунктами над головами коллег-программистов.
Вы делаете широкие предположения в своих точках: 1) выравнивание должно происходить только в начале строки, 2) выравнивание одинаковых вызовов на нескольких строках всегда будет в одном объекте "identifier.Method ()", 3) столбцовое положение имеет какое-либо отношение к именам идентификаторов, 4) выравнивание в комментариях может потребоваться только для «блоков ASCII со звездочками». Извини, -1.
Я обижаюсь не потому, что вы проголосовали против меня, а потому, что не предлагает ни малейшего контраргумента. По сути, ты просто пересказал мне мою точку зрения, ха. Но да, согласен! Выравнивание имеет значение только до тех пор, пока линии не различаются; выравнивание вызовов методов с разными аргументами НЕ имеет значения, потому что вы не должны ограничивать длину ваших имен переменных; положение столбца INDEED НЕ имеет ничего общего с именами идентификаторов; и единственное время, когда вам нужно выравнивание, - это когда вы занимаетесь искусством ascii за гроши компании.
Вы находитесь в пустой комнате с компьютером. Существует стандарт кодирования, который гласит, что по одному вызову метода на строку, плавные интерфейсы должны выравниваться по точке. На север нет выхода. Идти.
Что не так с выравниванием элементов в столбцах, например определений перечислений? А что, черт возьми, не так с искусством ASCII?
У кого-нибудь есть веские причины не использовать скриптовые шрифты? :)