Предисловие от переводчика
Однажды в блоге у одного хорошего знакомого DevRel-a я увидел статью на весьма необычную для разработчика тему — как выбрать хорошую схему для подсветки синтаксиса в IDE. Тема мне не чужда, часто приходится ковыряться в Python, а потому для меня вопрос цветовой схемы ни разу не праздный — от некоторых цветовых схем кровь из глаз (а они, глаза-то, увы, не казенные).
В общем, мы с коллегой-переводчицей, Псарёвой Елизаветой, перевели и адаптировали этот материал для вас.
Синтаксис подсвечивают, чтобы быстрее читать код или находить всякое в большом файле.
Подсветку можно использовать грамотно и безграмотно. Разберемся, как должен быть подсвечен синтаксис, чтобы вы могли облегчить себе работу.
Пестрота или кровь из глаз
Большая часть разработчиков ставят себе такую подсветку, что выделяется всё без разбору: переменные, ключевые слова, константы, знаки препинания, функции, классы, запросы, примечания и так далее.
Иногда цветов так много, что рябит в глазах. Вот здесь, на скриншоте, какой цвет — базовый?
Проблема в том, что если подсвечено всё, то не подсвечено ничего — текст сливается.
Проверить легко — найдите определение функции здесь
или здесь:
Улавливаете идею?
Подсвечивать всё подряд нельзя: нужно определиться, что акцентировать, а что нет.
По аналогии, в условной Jira нельзя всем задачам ставить высший приоритет — так не работает. У большинства задач должен быть обычный приоритет.
Как запомнить?
Подсветку выбирают в двух случаях:
Чтобы понимать назначение элемента по цвету (конечно, текст можно просто прочитать, но зачем тогда его вообще подсвечивать?)
Чтобы искать нужный элемент по конкретному цвету.
В первом случае, мы ищем элемент нужного назначения по цвету, а во втором - наоборот, цвет по назначению элемента.
На самом деле, этим поиском мало кто пользуется, даже если думает, что пользуется.
Посмотрите, что было до:
И после:
Видите, что я вместо return написал retunr, и его цвет изменился с красного на фиолетовый?
Я не вижу.
И еще. Закройте глаза (не сейчас! Сначала дочитайте предложение) и вспомните, какого цвета в вашей схеме имена классов?
Получилось?
Если в обоих случаях ответ “нет”, то схема бесполезна. Скорее всего ваша схема комфортна лично вам (типа я знаю, что если там что-то выделилось, то это код), но в качестве инструмента она бесполезна, ибо не работает.
Какие варианты? Используйте тот минимум цветов,которые способны запомнить. Например, в моей цветовой теме "Alabaster" используются только четыре цвета:
зеленый для строк;
фиолетовый для констант;
желтый для комментариев;
светло-голубой для определений верхнего уровня.
И всё! И, кстати, я написал это по памяти. Такой минимализм позволяет мне искать нужные элементы — если я ищу строку, то уверен, что она зеленая, а если я вижу что-то желтое, то это точно комментарий.
Цветов должно быть столько, сколько сможете запомнить.
Например, если в моем IDE поменять местами зеленый и фиолетовый, то будет катастрофа. Если кто-то поменяет цвета в вашем IDE, заметите?
Что подсвечивать?
То, чего мало. Помните — выделять нужно только самое нужное. Именно поэтому я не подсвечиваю переменные или вызовы функций — они есть везде, ваш код, вероятно, на 75% состоит из них.
Я подсвечиваю константы (числа, строки). Обычно они используются реже, но часто являются ориентирами — многие элементы начинаются с них.
Хорошо бы выделять верхнеуровневые определения — по ним можно быстро уловить структуру.
Отчасти выделить имена на фоне синтаксиса помогает пунктуация - в конечном счете вас интересуют именно имена, когда вы пробегаете глазами по коду.
И ради бога, не выделяйте class, function, if, else и т.п. — вы все равно обычно на них не смотрите. Да, вы возможно правильно задаетесь вопросом - где же этот if? - но в реальности вас интересует условие после него. Именно оно - важная, отличительная часть, а не if.
Подсвечивайте имена, константы. Приглушайте пунктуацию. Не подсвечивайте ключевые слова.
Комментарии тоже важны!
Привычка подсвечивать комментарии серым началась с тех времен, когда за код платили построчно. Взгляните на этот код:
Неудивительно, что такие комменты закрашены серым — они абсолютно бесполезны. Их специально так закрасили, чтобы в глаза не бросались.
Но вот хорошие, качественные комменты должны бросаться в глаза. Они ОБОГАЩАЮТ код. Такими комментами вы доносите то, что нельзя донести кодом напрямую. Они важны.
Так что вот вам, в итоге, тема для холивара:
Комментарии надо подсвечивать, а не прятать.
Пусть они будут яркими и бросаются в глаза. Если кто-то потратил время, чтобы их написать, значит, их точно нужно прочитать.
Два вида комментариев
Об этом мало кто говорит, но вообще-то, есть два вида комментов:
Пояснение
Закомменченный код
Во многих языках данные понятия равнозначны, так синтаксически вы их никак не выделите. Но можно следовать соглашению, типа как в SQL, где -- отличается от /* */.
Вот пример из Clojure, где хорошо видны эти два вида:
Закомменченный код код выделен серым, а пояснение — жёлтым.
Светлая или темная?
По статистике, 70% разработчиков выбирают темную тему. Я отношусь к остальным 30%. Почему так? Этот вопрос всегда ставил меня в тупик.
И, кажется, я нашел объяснение. Вот темная тема:
а вот светлая:
В светлой теме цвета выглядят бледнее. Вот я вынес их отдельно:
Обратите внимание, как много получилось цветов на темной плашке — запоминать бесполезно.
А на светлой их так мало получилось потому, что цвета темного спектра тусклее и грязнее. Посмотрите, как меняется палитра при уменьшении яркости:
Таким образом, если вы используете темный спектр на светлом фоне, у вас для подсветки остается не так много цветов. Например, вы не сможете выбрать какой-нибудь темно-желтый или темно-синий так, чтобы они контрастно смотрелись.
В целом, нет такого волшебного цвета, который хорошо бы контрастировал и хорошо бы смотрелся на белом фоне. Соответственно, выбирая светлую тему, вам будете ограничены цветами темного спектра, которые еще и между собой плохо различимы.
Вот вам и разгадка статистики. Темная тема смотрится лучше, чем светлая. Что поделать, наука — ¯\_(ツ)_/¯.
Но!
Но.
Есть хитрость, о которой мало кто знает — используйте цвет фона текста! Сравните:
В первом блоке цвет строки достаточно яркий, но контрастность низковата — текст читать трудно.
Во втором блоке, контрастность строки хороша, но цвета текста сливаются.
На последней строке все хорошо и с контрастностью, и с яркостью. Светлые цвета в этом случае легко читаются даже на белом фоне, поскольку фон за ними занимает больше места. Яркость текста там такая же, как и во втором примере, но выглядит текст четче. Всё очень сложно.
Конечно, UI-дизайнеры об этом приёме знают давно, но в IDE я его применение вижу редко.
Если в вашем IDE можно делать фоновый цвет текста, попробуйте — вдруг откроете для себя светлые темы.
Полужирное и курсивное начертание
Не используем! Проблема прежняя — слишком много акцентов. У форматирования функция такая же, что и у подсветки, а подсвечивать все подряд нельзя.
Теоретически, подсветку на типографику заменить можно. Будет ли это работать лучше? Без понятия, я никогда не видел подобных примеров.
Вот как выглядит использование полужирного и курсивного начертания вместо подсветки.
Миф об схеме, где всё по науке
Есть подсветки, где всё выверено и выровнено согласно науке — у всех цветов одинаковая яркость или цвета распределены на круговой палитре строго равномерно.
Наверное, это могло быть красиво (и даже удобно для OCR) — но в реальности вся эта красота не работает:
OkLab l=0.7473 c=0.1253 h=0, 45, 90, 135, 180, 225, 270, 315
Смысл подсветки — сделать штуки заметнее. Но если эти штуки будут одинаковой яркости и цветности, то они станут похожими, и их будет сложно различать.
Зрение лучше воспринимает именно разную яркость, а не разные цвета. И этим надо пользоваться, а не игнорить.
Вместе разрабатываем правильную схему
Вспомним все правила, о которых мы говорили выше, и посмотрим, что получится. За основу мы возьмём тему, которую я показывал в самом начале:
Сначала уберем подсветку ключевых слов и вернем базовый цвет:
Далее уберем подсветку переменных:
То же самое делаем с вызовами функций и методов:
Суть в том, что в своем коде вы в основном ссылаетесь на переменные и вызываете методы. Если вы начнете их подсвечивать, выделится больше 75% кода.
Заметьте, мы не стали трогать объявления переменных. Они встречаются не так часто. С их помощью можно понять, откуда берется то или иное значение.
Затем приглушаем пунктуацию:
Так имена будут лучше видны, ведь именно они помогут вам понять, что происходит в коде. Чего не скажешь о скобках.
Хотя можно базовый цвет оставить и для пунктуации:
Почти закончили. Теперь подсветим комментарии:
Не используем красный! Он нужен для ошибок и проблемных строк кода.
Пока многовато цветов, нужно убрать еще один. Подсветим одинаково числа и строки:
Почти всё. Немножко подкрутим яркость — всё должно быть понятно, поэтому имена функций делаем ярче (желтым), чем имена переменных (синим).
Сравним исходную и итоговую версии:
Как по мне, у нас получилась рабочая схема — и глаза не болят, и всё, что нужно, найти легко.
Минутка саморекламы
Всеми этими приемами я пользуюсь около 8 лет.
Я создал свою схему и назвал её Alabaster. Несколько раз она применялась для таких IDE, как:
Sublime Text (дважды).
Эту схему уносили и во многие другие редакторы и терминалы (полный список лежит тут). Если вашего IDE там нет, попробуйте найти в нем схему по названию — возможно, ее уже туда встроили! Мне всегда было интересно, откуда в разных IDE берутся эти схемы, хотя я и автор одной из них (но я всё равно не знаю, откуда они взялись).
Вы можете использовать Alabaster, как вам угодно или же создать свою схему по принципам из этой статьи.
Я разработал то, что будет удобно именно мне и ни разу не пожалел. Мне обычно хватает одного взгляда на любую «классическую» цветовую схему, чтобы отбить желание ею пользоваться.
Подозреваю, что мы не видим более спокойных схем только потому, что никто всерьез об этом не задумывался. Ну вот, теперь задумаетесь. Надеюсь, что эта статья показала, как более грамотно использовать подсветку и как менять схемы по умолчанию.
Комментарии (28)
LeshaRB
18.11.2025 21:49Вроде было
LinkToOS
18.11.2025 21:49А не помогло. Люди все равно подсвечивают неправильно. Поэтому вышла статья с новым названием - "Увы, ваш синтаксис (все еще) подсвечен безграмотно."
SaihonFox
18.11.2025 21:49а смысл пытаться впихнуть людям свою подсветку? если людям не понравилось то это их проблема. или вы мани за это получаете?)
dom1n1k
18.11.2025 21:49И ради бога, не выделяйте
class,function,if,elseи т.п. — вы все равно обычно на них не смотрите. Да, вы возможно правильно задаетесь вопросом - где же этотif? - но в реальности вас интересует условие после него. Именно оно - важная, отличительная часть, а неif.Я не согласен.
Это - визуальные якоря, за которые глаз цепляется, как за выступы на склодроме.
Или, если хотите, как буллеты в списке, которые меня тоже не интересуют сами по себе - но они выпирают из текста и помогают ориентироваться.
SquareRootOfZero
18.11.2025 21:49Согласен (с вами, не с автором). Оно, конечно, отступы - но что там, перед отступом? Это if, это then, это else, это try, это пуля, это самолёт? И вот уже надо вчитываться, чтобы понять, что там за Супермен. А зачем вчитываться, когда можно не вчитываться - по цвету сразу понимаешь, о чём будет следующий блок.
edogs
18.11.2025 21:49Есть у нас подозрение, что писать о грамотных читаемых интерфейсах и показывать все это на примере темы с выворткой шрифта, использование чего и по санпину считается некорректным и по исследованиям делает текст более трудно воспринимаемым, это какой-то тонкий троллинг. Да, мы видели что пара слов о светлой теме тоже сказана, но в основном в контексте "ее никто не любит и этому есть причины".
AndreyDmitriev
18.11.2025 21:49Я как раз на светлой стороне, и не поленился да поставил Alabaster для VSCode. При всём уважении к усилиям автора, комментарии (да и вообще что бы то ни было при отсутствии ошибок) выделять красным цветом - это зло.
Andy_U
18.11.2025 21:49Цветов должно быть столько, сколько сможете запомнить.
Сколько можете различить...
И вы еще забыли про bold (алгол!!!), italics, underscoring ;)
LinkToOS
18.11.2025 21:49Сколько можете различить...
Нет, именно запомнить, и автоматически реагировать на любое несоответствие. Он дает пример. Операторы у него подсвечены фиолетовым, а другой тип красным. Он сделал опечатку - напечатал retunr вместо return (оператор). И цвет поменялся с фиолетового на красный. Если четко помнить что нормальный return должен быть фиолетовым, а не красным, тогда даже при беглом взгляде опечатка сразу будет замечена.
Andy_U
18.11.2025 21:49Нет, именно запомнить, и автоматически реагировать на любое несоответствие.
Так это разные вещи. Попроси меня назвать цвет чего-нибудь относительно редко используемого в палитре, так не назову, а на экране увижу.
Операторы у него подсвечены фиолетовым, а другой тип красным.
А вот пример из статьи я даже обсуждать не хочу. Красно-фиолетово-синяя палитра мне резко некомфортна.
Если четко помнить что нормальный return должен быть фиолетовым, а не красным, тогда даже при беглом взгляде опечатка сразу будет замечена.
Да недо помнить, Мне PyCharm поможет, отметив ошибку красным справа и подчеркнув eё в коде.
LinkToOS
18.11.2025 21:49Красно-фиолетово-синяя палитра мне резко некомфортна.
Конкретные цвета в этом примере значения не имеют. Сам принцип - конкретная конструкция имеет характерную для нее раскраску. Мозг привыкает, и когда раскраска отличается от характерной для этой конструкции, это сразу привлекает внимание.
SquareRootOfZero
18.11.2025 21:49Тут ещё во многом дело привычки, особенно с моментами вроде "светлая тема vs. тёмная тема": пересаживаешься по каким-то причинам с тёмной на светлую - осспади, как можно это терпеть; пересаживаешься спустя какое-то время обратно на тёмную - божэ, ужос, глаза вытекают; пользуешься какое-то время тёмной темой в одном редакторе, а светлой - в другом - уже кажется, что и там, и там нормально, зачем что-то менять. Bold вместо цвета - в моей теме для Питона так выделены class и def, нормально. Когда вместо "return" написал "retrun" - в языках с объявлением переменных подчеркнёт, как ошибку, да даже и в Питоне с настроенным LSP выдаст предупреждение, что "переменная нигде не используется", так что есть там цвет, нет там цвета - какая разница (хотя выделять отдельным цветом ключевые слова языка, по-моему, надо). Из объективного в статье, разве что, про избегание пестроты. Но это неточно. Ну и шрифт ещё выбрать правильный, чтобы строчную L с заглавной i не путать, хотя это уже не про подсветку синтаксиса.
AppCrafter
18.11.2025 21:49как-то непонятно написано про светлую и тёмную темы. Автор вроде как ратует за цветовую палитру светлой темы, а на картинках цвета для чёрной плашки смотрятся лучше.
ExTalosDx
18.11.2025 21:49Я за миллисекунду нахожу там где подсветка есть.
Т.к я за 7 лет работы научил мозг.
Правда у меня и подсветка другая, не вырвиглазная
ic10
18.11.2025 21:49Я тоже приходил к такому выводу, что новогодняя елка -- это не лучшая стратегия подсветки синтаксиса. Что-то даже пытался делать у себя. В Vscode наиболее близка к этому тема Visual Studio, но и она не идеальна, кое-что приходится менять.
Вообще, тут может быть две стратегии подсветки:
Ограниченное кол-во цветов -- я точно знаю за что отвечает каждый цвет.
Новогодняя елка, но смысл не в том, чтобы знать для чего каждый цвет, а просто визуально отделять один токен от другого и неважно за что они отвечают, это уже определяется по контексту.
Какая правильней -- не знаю. Наверное, если бы какая-то из них была сильно эффективней, ее бы все и использовали, и споров не было. Мне больше нравится первая.
Forthright
18.11.2025 21:49Спокойно помню все цвета своей темы, при том что подсвечено большинство элементов. Объявления и вызовы функций одним цветом; названия типов, классов, перечислений, и ключевые слова с ними за компанию, другим; третьим цветом строки; по отдельному цвету для членов классов, локальных переменных, параметров и глобальных переменных; и ещё пара-тройка цветов на всё остальное. Отлично могу понять что из себя представляет элемент просто посмотрев на его цвет. Просто пробежавшись взглядом по коду можно спокойно оценить какие функции вызываются, к каким членам класса идёт обращение, есть ли доступ к глобальным переменным и много ещё чего подобного. Так что это исключительно вопрос привычки, как по мне.
baldr
18.11.2025 21:49Слушайте, а давайте вы не будете мне указывать каким цветом и в какой теме я буду набирать буковки в коде? Это моё дело каким IDE пользоваться, если я делаю работу нормально.
Возьмите мой код, откройте в своём любимом VSCode и со своей подсветкой - и спокойно делайте ревью. Если я пишу плохо или медленно - это я могу обсудить. Если я пишу не с тем цветом кода - я могу показать где я крутил это ваше мнение.
Что значит "неправильно"? Что за ерунда? Я уже 25 лет пишу код, я могу для себя сам решить как мне удобно это делать?
У меня файл-браузер (Double Commander) со странной цветовой схемой - белый шрифт на зеленом фоне. Я знаю что человека со стороны может стошнить с непривычки. Я не помню почему я когда-то поставил такие цвета - скорее всего это был старый CRT-монитор и стандартные выжигали глаза. Но мне теперь это привычнее и после переустановки софта я ставлю эти цвета опять.
cupraer
18.11.2025 21:49Есть миллиард цветовых недоразумений в стиле «я так вижу», и есть Nord. https://www.nordtheme.com/
hex_coder
18.11.2025 21:49Как только увидел светлую тему, у меня аж глаза заболели. Сразу прокрутил в другое место и уменьшил яркость экрана.
Белый цвет на экране монитора - это тысячи искусственных лампочек, поэтому я стараюсь сделать так, чтобы его было как можно меньше. Если тема светлая, то это ок, у меня такие тоже используются. Но если цвет фона - белый, то там уже никакие цвета не спасут, потому что смотреть на это надо внимательно.Кажется, что светлую тему выбирают из-за того, что в большинстве веба цвета светлые. Если постоянно переключаться между кодом и страницей, то всё будет очень контрастно. Светлая страница будет слишком яркой - надо будет уменьшать яркость, тёмный код будет слишком тусклым - придётся увеличивать яркость. То есть или терпеть, или постоянно крутить яркость.
Использую Mariana-Gray и кастомизированный Monokai.
cupraer
18.11.2025 21:49в большинстве веба цвета светлые
Не знаю ни одного адекватного сайта, который бы не заглядывал в дефолтные системные настройки и не использовал тему, предпочитаемую пользователем. Поставьте темную системную тему — и все нормальные сайты (кроме банков, да) подстроятся.
LinkToOS
18.11.2025 21:49Если постоянно переключаться между кодом и страницей, то всё будет очень контрастно. Светлая страница будет слишком яркой - надо будет уменьшать яркость
Если есть качественная веб-камера, то можно попробовать записать видео, и посмотреть как изменяются зрачки при переключении окон с разной яркостью.
Наверно даже есть программы, которые в помощью вебки позволяют вести мониторинг состояния глаз при работе за компьютером. Отслеживать покраснение, частоту моргания, признаки спазма аккомодации.
georgiy08
18.11.2025 21:49Конечный результат выглядит так, как будто IDE загрузила проект, но не успела его проиндексировать.
Делать одним цветом числа и строки для меня непонятно и может только сбить.
С моим мнением конечно можно быть несогласным, но подсветка кода и тема IDE в первую очередь составляется так, чтобы уменьшить нагрузку на глаза. Да и не думаю, что разработчики сред разработки не консультируются ни с кем касаемо того, как лучше сделать базовую тему подсветки синтаксиса.
kryvichh
18.11.2025 21:49Что-то на скринах отсутствуют вертикальные линии для структурных блоков. Полезная вещь.
domix32
18.11.2025 21:49Каэш на вкус и цвет все фломастеры разные, но совершенно не понимаю как так у автора сложилось, что объявление переменной и её использование стали разного цвета. Красить одинаково числа и строки зло, примерно также как не иметь разницы между 0 и о.
Вопрос про класс не понял - у многих языков его просто может не быть, у других аналогичных объявлений может быть несколько вариантов, да ещё и с параметризацией (генерики, датакалассы, всякие сум-типы).
К исходной подсветке тоже есть вопросы - почему объявление переменной желтое, а обращение к ней красное, почему тогда аргумент не жёлтый?
Отдельно момент возможностей подсветки - многие IDE просто не могут поддержать всё множество классов токенов для всех языков. Тот же С/С++ имеет варианты с вызовами макросов, функций и конструированием классов. Там с одной только индентацией проблем не оберёшься, не говоря уже о корректной подсветке всех этих вариантов. TreeSitter многое умеет, но в опредеённые моменты придётся учить IDE как-то принимать дополнительные правила, которые не просто структурировать, особенного когда в файле используется несколько языков - html + css + js или скажем python + sql, а то и вовсе какой-нибудь отдельный DSL - возьмите те же токены документирующих комментариев: всякие
@brief,@param, и прочие. А уж если тестов в комментарий завернули или пример кода.Ну, и отдельно стоит заметить, что на мой вкус белый слишком яркий и ключевой слово должно отличаться от переменной.
YegorP
Тут отдельно нужно вспомнить, что в большинстве случаев когда говорят про подсветку синтаксиса, то подсвечена всего лишь лексика. Раскрашивание ключевых слов и пунктуации даже не требует синтаксического разбора. То есть эта фича глупее, чем называется. Ну и проблемы с этим соответствующие.
В последние годы, правда, наметился сдвиг в IDEшках, которые теперь таки парсят код чтобы раскрасить его поумнее. Даже семантической подсветкой это называют.