Предисловие от переводчика

Однажды в блоге у одного хорошего знакомого DevRel-a я увидел статью на весьма необычную для разработчика тему — как выбрать хорошую схему для подсветки синтаксиса в IDE. Тема мне не чужда, часто приходится ковыряться в Python, а потому для меня вопрос цветовой схемы ни разу не праздный — от некоторых цветовых схем кровь из глаз (а они, глаза-то, увы, не казенные).

В общем, мы с коллегой-переводчицей, Псарёвой Елизаветой, перевели и адаптировали этот материал для вас.

---

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

Подсветку можно использовать грамотно и безграмотно. Разберемся, как должен быть подсвечен синтаксис, чтобы вы могли облегчить себе работу.

Пестрота или кровь из глаз

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

Иногда цветов так много, что рябит в глазах. Вот здесь, на скриншоте, какой цвет — базовый?

Проблема в том, что если подсвечено всё, то не подсвечено ничего — текст сливается.

Проверить легко — найдите определение функции здесь 

или здесь:

Улавливаете идею? 

Подсвечивать всё подряд нельзя: нужно определиться, что акцентировать, а что нет.

По аналогии, в условной Jira нельзя всем задачам ставить высший приоритет — так не работает. У большинства задач должен быть обычный приоритет. 

Как запомнить?

Подсветку выбирают в двух случаях:

1. Чтобы понимать назначение элемента по цвету (конечно, текст можно просто прочитать, но зачем тогда его вообще подсвечивать?)

2. Чтобы искать нужный элемент по конкретному цвету.

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

На самом деле, этим поиском мало кто пользуется, даже если думает, что пользуется.

Посмотрите, что было до:

И после:

Видите, что я вместо return написал retunr, и его цвет изменился с красного на фиолетовый?

Я не вижу.

И еще. Закройте глаза (не сейчас! Сначала дочитайте предложение) и вспомните, какого цвета в вашей схеме имена классов?

Получилось?

Если в обоих случаях ответ “нет”, то схема бесполезна. Скорее всего ваша схема комфортна лично вам (типа я знаю, что если там что-то выделилось, то это код), но в качестве инструмента она бесполезна, ибо не работает. 

Какие варианты? Используйте тот минимум цветов,которые способны запомнить. Например, в моей цветовой теме "Alabaster" используются только четыре цвета:

• зеленый для строк;

• фиолетовый для констант;

• желтый для комментариев;

• светло-голубой для определений верхнего уровня.

И всё! И, кстати, я написал это по памяти. Такой минимализм позволяет мне искать нужные элементы — если я ищу строку, то уверен, что она зеленая, а если я вижу что-то желтое, то это точно комментарий.

Цветов должно быть столько, сколько сможете запомнить.

Например,  если в моем IDE поменять местами зеленый и фиолетовый, то будет катастрофа. Если кто-то поменяет цвета в вашем IDE, заметите?

Что подсвечивать?

То, чего мало. Помните — выделять нужно только самое нужное. Именно поэтому я не подсвечиваю переменные или вызовы функций — они есть везде, ваш код, вероятно, на 75% состоит из них.

Я подсвечиваю константы (числа, строки). Обычно они используются реже, но часто являются ориентирами — многие элементы начинаются с них.

Хорошо бы выделять верхнеуровневые определения — по ним можно быстро уловить структуру. 

Отчасти выделить имена на фоне синтаксиса помогает пунктуация - в конечном счете вас интересуют именно имена, когда вы пробегаете глазами по коду.

И ради бога, не выделяйте class, function, if, else и т.п. — вы все равно обычно на них не смотрите. Да, вы возможно правильно задаетесь вопросом - где же этот if? - но в реальности вас интересует условие после него. Именно оно - важная, отличительная часть, а не if.

Подсвечивайте имена, константы. Приглушайте пунктуацию. Не подсвечивайте ключевые слова.

Комментарии тоже важны!

Привычка подсвечивать комментарии серым началась с тех времен, когда за код платили построчно. Взгляните на этот код: 

Неудивительно, что такие комменты закрашены серым — они абсолютно бесполезны. Их специально так закрасили, чтобы в глаза не бросались. 

Но вот хорошие, качественные комменты должны бросаться в глаза. Они ОБОГАЩАЮТ код. Такими  комментами вы доносите то, что нельзя донести кодом напрямую. Они важны.

Так что вот вам, в итоге, тема для холивара:

Комментарии надо подсвечивать, а не прятать.

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

Два вида комментариев

Об этом мало кто говорит, но вообще-то, есть два вида комментов: 

1. Пояснение 

2. Закомменченный код

Во многих языках данные понятия равнозначны, так синтаксически вы их никак не выделите. Но можно следовать соглашению, типа как в 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, как:

• VS Code;

• JetBrains;

• Sublime Text (дважды).

Эту схему уносили и во многие другие редакторы и терминалы (полный список лежит тут). Если вашего IDE там нет, попробуйте найти в нем схему по названию — возможно, ее уже туда встроили! Мне всегда было интересно, откуда в разных IDE берутся эти схемы, хотя я и автор одной из них (но я всё равно не знаю, откуда они взялись).

Вы можете использовать Alabaster, как вам угодно или же создать свою схему по принципам из этой статьи.

Я разработал то, что будет удобно именно мне и ни разу не пожалел. Мне обычно хватает одного взгляда на любую  «классическую» цветовую схему, чтобы отбить желание ею пользоваться. 

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