Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 73
Закреплённые комментарии
Когда программисту делать нечего - он цвета настраивает (С).
Проблема в том, что если всё выделено, то ничто не выделяется.
По этим соображениям я сделал абсолютно серый интерфейс. Цветом выделяются только немногие детали, вроде курсора, ok/cancel, да и то неброско.
Скрытый текст
Статья вкусовщина, не более того.
Согласен, не многие испытывают такие проблемы. Но это похоже на то, какой шок я встречаю каждый раз посещая какой-то большой магазин… приходишь к этому огромному стенду с множеством однотипных товаров, но глаза разбегаются, я начинаю теряться в этом ассортименте предложений…
О боже, какое это паршивое чувство. И да, думаю не все лишь страдают такими ментальными проблемами.
В защиту темной темы - один раз пытался со светлой день поработать - к вечеру глаза чесаться от усталости начали.
Не знаю, как у вас, но у нас в шарпах в вижл студии дефолтная подсветка синтаксиса на темном фоне - зашибись
Согласен, вполне!
На дотнете 10 лет и VS - единственная IDE где использую светлую тему. Вот буквально везде использую темную (даже на телефоне и в обсидиан), а в студии белую. Привычка, похоже, но на темную никак не могу пересесть, очень уж нравится сочетание цветов в комбинации с кодом на шарпе)
В шарпах вижал студии синяя тема ...
Яркость монитора бы проверить и окружения. Если закрыли все блэк-аут шторами, а яркость на мониторе 100, то я бы со светлой темой даже часа бы не смог проработать.
Когда программисту делать нечего - он цвета настраивает (С).
Многие (в том числе и я) используют подсветку для эстетичного и приятного вида. Если брать отсутствие подсветки, то появляется впечатление сосоставимо с тем , как написание кода программы в одну строку
Мне жаль, но перевод топорный.
Ну и сходил я по ссылке на оригинал - как-то не хочется слушать про дизайн от людей, которые используют ядовито-жёлтый как фон для странички.
Явно не хватает примера с retunr в конце.
Крайне странные аргументы.
Пример с поиском функций: я гораздо быстрее нашёл их в подсвеченном коде, потому что во втором подсвечены практически только комментарии — ну глаз в первую очередь за них и зацепился, а остальной текст весь сплошняком серый, надо вчитываться, что там где.
Пример с retunr: а с какой радости несуществующий идентификатор оказался подсвеченным красным цветом? Мне не попадалось редакторов, где расцвечивался бы дефолтный текст, не подпадающий ни под одно правило. Если сами задали такую оцветовку — сами себе Буратины.
Рекомендация не подсвечивать ключевые слова вообще непонятна: эти цвета позволяют моментально идентифицировать основные синтаксические конструкции языка. Не говоря уж о визуальном предупреждении, если попытаешься создать переменную или функцию с именем, совпадающим с каким-то редко используемым и потому забытым (или недавно появившимся) ключевым словом.
Вот "идеальная" подсветка, потому что она моя. Я её подогнал под себя, так, как мне лично удобно.
Ну а если чуть серьезно, то подсвечиваться должны ключевые слова языка: зарезервированные слова, языковые конструкции, операторы, константы, типы. Но не переменные или другой уникальный для проекта текст.
Почему одинаковые слова в рамках одной части кода подсвечиваются по-разному?
Первое объявление переменной голубым цветом чтобы "знать откуда ноги растут"
Да, в этом есть смысл. Но, на мой личный взгляд, просто видеть "откуда ноги растут" - не очень полезно, по этому удобнее, либо поставить курсор и подсветить все использования переменной, либо перейти к объявлению. А так, это добавляет лишний акцент на код
Я другой вариант выдумал. Надо что-то выделить, кликнул по кнопке на интерфейсе, — оно подсветилось, кликнул еще раз, подсветка офф. Типо нужно комментарии отсветить — тяпнул по кнопке, ушло, и наоборот, надо подсветить переменные — клинкнул, нашел, радуешься, потом тяпнул по кнопке, и все, ничего не отвлекает.
А не лучше ли для этой цели подсветить ключевое слово "const"?
Здесь код Джуна. Функция как называется? А делает что?
Изи утечки памяти, а чел видит только проблемы синтаксиса. Ну тоже джун получается. А говорят джун джуну глаз не выколет
Подозреваю, единственная причина, по которой мы не видим более сдержанных цветовых схем, заключается в том, что люди никогда об этом не задумывались.
В основном с автором согласен, но в этой фразе категоричная лож.
Собственноручно разработал чёрно-белую тему, которой пользуюсь и не имею желания заменить на "новогоднюю ёлку". В теме задействованы лишь восемь оттенков от чёрного до белого. Есть два варианта: светлый и тёмный. Предпочитаю светлый. И да, курсив не используется, ключевые слова выделяются жирным, строки более светлым оттенком, а комментарии выделяются фоном.
Хорошие комментарии дополняют код
Код первичен, а комментарии зависят от него, их нет никакого смысла выделять. Если вы заострили внимание на определенном участке кода, то едва ли серый цвет помешает ознакомиться с пояснением рядом. И вряд ли понадобится рыскать по файлу в поисках нужного комментария, не обращая внимание не структуру кода.
Ещё один секрет, о котором никто не говорит, заключается в том, что существует два типа комментариев:
Закомментированный код
Секрета нет, просто закомментированного кода не должно быть, ибо место ему - без комментирования в отдельных экспериментальных ветках или документации, а здесь это будет просто мусором.
Вот с одной стороны вы правы и я с вам абсолютно согласен.
А с другой - вот есть функционал, который сейчас нельзя включать, но в последствии он будет нужен, что с ним делать?
В отдельной ветке его оставить? - так разработчик который через пол года задачу возьмёт, эту ветку ни за что в жизни не найдет. (Ой и не говорите вписать в задачу - эту задачу закроют, а через пол года новую заведут, и комментарии к старой уже никто не посмотрит)
В if (false) или не дай бог фиче тоггл завернуть - так не очевидно будет, что этот код не работает, а с тогглом ещё и скрыто. Это может привести к попыткам исправить код, который даже не присутствует в скомпилированной версии например.
В документацию его вписать? Опять же, разработчик через пол года взявший доработку - не будет там искать, он пойдет в место в коде откуда ноги растут.
Так что вот это "не допускать закомментированного кода" - хорошо, когда этим кодом владеешь ты и только ты. А если есть ещё человек, то даже в банальном случае - ты удалил код потому что он не нужен в этом релизе - а следующий разработчик не зная что эта фича была - написал её заново через один релиз а не вытащил из гита.
И главная проблема закомментированного кода "все забыли откуда он и что делает" - легко решается посмотром по истории гита, а вот обратная - угадать где когда-то был код, чтобы его восстановить - нет.
не говорите вписать в задачу - эту задачу закроют, а через пол года новую заведут
Именно это и скажу. Тот, кто принимает решение о приоритете задач обычно читает не код, а джиру. А если бэклог выглядит плоской помойкой без структуры, где всё теряется, то и высыпание мусора из нее себе под ноги ничего не даст, кроме повышенной когнитивной нагрузки и раздражения программистов.
Ну уж на крайний случай, если есть твердая уверенность, что эта доработка скоро понадобится, можно сделать компактный TODO-коммент с указанием на таску, где будет человеческаое описание целей с задачами и прилинкована ссылка на ветку с нужными коммитами. Но никак не зеленая лавина. И это не напоминание о том, что задачу надо делать.
Если же такой уверенности нет и пройдет порядочно времени, то такой код потерять не жалко, ведь его актуализация может занять сравнимое количество времени с разработкой с чистого листа.
В if (false) или не дай бог фиче тоггл завернуть - так не очевидно будет, что этот код не работает
Магическиие константы - это, вообще говоря, антипаттерн, у фича-флага должно быть говорящее имя (вроде ${featureName}Enabled). Если вам необходимо так гибко управлять включением фич, то наверняка будет полезно прокидывать его значение из основных настроек/переменных окружения/etc, чтобы не ползать по кодовой базе в поисках необходимого.
удалил код потому что он не нужен в этом релизе - а следующий разработчик не зная что эта фича была - написал её заново через один релиз а не вытащил из гита.
Если же вариаций мало и они известны на этапе сборки, то для разных дистрибутивов можно сделать просто разные корневые ветки (то есть форки). Или как вы себе представляете, скажем, хотфикс для первого релиза после второго, туда-сюда вручную изменения гонять?
будет полезно прокидывать его значение из основных настроек/переменных окружения
Вот это как раз приведёт к тому, что человек который придет кодить рядом скорее всего предположит что код уже работает, и будет учитывать его в расчетах - на что потратит больше времени и сил. Я уже не раз видел ситуацию когда человек шел отладить код, за выключенным фиче тогглом, потому что считал виновником ошибки.
Именно это и скажу. Тот, кто принимает решение о приоритете задач обычно читает не код, а джиру. А если бэклог выглядит плоской помойкой без структуры, где всё теряется...
На реальных проектах работают люди, у них не бывает ни идеального бэкдога ни идеального руководства. Модель поведения для сферического идеального проекта в вакууме - это конечно хорошо, но паттерны проведения как раз направлены на минимизацию последствий от плохого окружения, если они работают только в идеальном - они мусорные.
человек который придет кодить рядом скорее всего предположит что код уже работает
У него нет оснований так предполагать. Если есть явный условный переход, значит, условие может быть как истинным, так и ложным.
Но если нет кода - нет и сомнений. Поэтому разные ветки при прочих равных предпочтительнее.
На реальных проектах работают люди
Чтобы суметь таске указать родительскую фичу не нужно быть суперменом. Для эффективной работы нужно выстраивать процессы, это непосредственная задача менеджмента.
Ну вы точно живёте в каком то другом мире, где люди не ошибаются и задачи планируются сразу, целиком, и наверное даже без АБ тестов.
Вы говорите - нет оснований предполагать - а ко мне два раза приходили люди, которые пытались починить код, который даже не исполнялся. Если есть место где можно ошибиться - будьте уверены, ошибутся.
Вы говорите - что задача указать родительскую таску простая - а я прямо сейчас работаю над задачей у которой уже 12 итераций - и если бы ссылка на какую то часть её работы например была в комментариях к одной из тасок, которые с учётом правок и дополнений уже на поэму тянут - черт ногу сломает её найти.
Главная задача менеджмента - адаптировать стратегию под возникающие задачи в реальном времени. И если сейчас сделали задачу, а потом оказалось что надо распилить функционал пополам, потом сделать две итерации над одной частью, потом АБ тесты, потом ещё что-то, никто не будет тащить комментарий о том, в какой ветке спрятана вторая половина функционала.
вы точно живёте в каком то другом мире, где люди не ошибаются и задачи планируются сразу
Низкая квалификация и недобросовестная работа - это ошибка выбора профессии, в таких "мирах" я стараюсь не задерживаться. Чего и другим желаю.
приходили люди, которые пытались починить код, который даже не исполнялся
То есть они не умеют пользоваться отладчиком и не удосужились воспроизвести проблему, которую собрались чинить.
работаю над задачей у которой уже 12 итераций
12 раз переделывать одну фичу - это похоже на безумие само по себе) Звучит, как процессы стартапа под конец бюджета, когда требования рождаются по ходу пьесы и нет времени на исследование кодобазы перед взятием фичи в разработку. Почему так? Никто заранее не знал, что те же А/Б тесты нужны?
если сейчас сделали задачу, а потом оказалось что надо распилить функционал пополам, потом сделать две итерации над одной частью, потом АБ тесты, потом ещё что-то, никто не будет тащить комментарий о том, в какой ветке спрятана вторая половина функционала.
Даже если наивно делать сторю, в которой по каждой доработке заводить сабтаску с говорящим названием, одна из которых будет про сплит функционала, то найти необходимое не составит труда.
была в комментариях к одной из тасок, которые с учётом правок и дополнений уже на поэму тянут
Если следовать git flow или подобной методологии, где каждая единица работы делается в отдельной ветке, и id таски в имени, то проблем с поиском не должно быть.
в нормальных языках есть условная компиляция. а в ненормальные её стоит добавить, хотя бы при помощи комментариев специального назначения.
хорошо, когда этим кодом владеешь ты и только ты.
Даже так - нет. Код который написал другой программист и код который написал ты но полгода назад - суть одно и то же.
Мне понравилось. Ни со всем соглашусь (в плане личных предпочтений), но я задумался. Вкусовщина -да , но не за ради красоты мы цвета меняем. Хорошо когда цвет позволяет быстро цепляться за важное глазом. Вообще мы это и так, обычно, подчёркиваем настройкой цветов, и часто это субьективно и зависит от образа мышления, но я пару моментов для себя лично в статье отметил. Автору спасибо!
Я все же думаю, нет правильных или неправильных расцветок. Это одна из тех вещей, которые сугубо индивидуальны. Главное, чтобы расцветка работала для конкретного человека - этого достаточно.
Плюс задачи у разных людей разные. Кто-то хотел, как автор, чтобы акцентов было поменьше, но все они были поярче. А у кого-то задача была противоположная: он хотел, чтобы разные сущности были равноудалены друг от друга по внешнему виду, даже если это выглядит как новогодняя ёлка.
Для примера: в языке Go переменная пакета, константа, поле структуры, метод-значение и метод-выражение могут выглядеть похоже - xxxxx.Xxxxx. Кому-то это вполне комфортно, а кто-то использует цвет, чтобы добавить различий. Все по-своему правы.
Так что если вы чувствуете комфорт со своей подсветкой синтаксиса - ничего менять не нужно, вы все делаете правильно.
Помните, как Торвальдс в интервью для Гитхаба сказал, что его редактор не имеет "новомодных фич типа подсветки синтаксиса"... Или тот чел с Ютуба (тоже разработчик ядра), который за 3 часа в Виме без конфига и подсветки синтаксиса написал USB драйвер для конкретного устройства... Жесть в общем
Ну главное же знания, подсветка - лишь помощь, чтобы понять ошибся ты где-то или нет, правильно ли определился тип того или иного выражения и т.п.
Но юсб драйвер "в блокноте" это сильно все равно)
Ну в целом да, просто есть вот такие уникумы в хорошем смысле, которые олдскульно пишут код без подсветки, потому что привыкли так делать. Ещё люди в комментариях в такие моменты просто ошалевают, потому что для героев видео подсветка синтаксиса — это «fancy feauture», а для зрителей, по их же словам, — необходимость...
Когда бездельничаю, люблю почитать про проблемы программистов: то какую тему лучше использовать, то про эргономию рабочего места, то про разделённые убер клавиатуры, то про изогнутые ультра широкие мониторы, то как работать с помидор-таймером... И даже про выгорание. Интересно же, как другие кодят :-)
15 лет пишу код в VS на C#, сначала спокойно пользовался светлой темой, пару-тройку лет назад переключил на тёмную ради интереса. Цвета в коде устраивают как есть.
Как увидел подсветку синтаксиса: красный, фиолетовый, жёлтый, зелёный... Красный основной! Ппц... Вкусовщина, понимаю) Но всё же, это ППЦ!)
Вот ещё один тест. Закройте глаза (ещё нет! сначала дочитайте это предложение!) и попытайтесь вспомнить, какой цвет ваша цветовая тема использует для имён классов.
Фиолетовый :3
Цвета темы для меня лично всегда играли роль скорее красивостей уровня цветовой палитры в терминале. Я с детства читаю очень быстро, и всегда легко находила в тексте нужное мне, даже если открывала файл в блокноте. Собственно говоря, я и тему поэтому свою любимую какую-то не имею, и просто устанавливаю то, что подходит под палитру, которую использую в своей ОС.
Даже более того, для меня лично чем более цветастые цвета, тем легче мне читать. Основная задача при чтении для мозга это разделять токены, и если они уже разделены цветом, то читать становится куда легче.
Не стоит, конечно, думать, что стоит поставить Comic Sans с красным, кислотно-зелёным и синим на ярко-жёлтом фоне и все будет читаться прекрасно... Впрочем, ради интереса я так однажды и сделала, играясь с настройками темы в Rider, и код даже вполне читался там, где хватало контраста.
Скриншот сколько-то там летней давности, не открывать впечатлительным и беременным старикам, очень ярко
К сожалению, светлые темы я не любила и не люблю, поэтому даже пытаться использовать не стала, но память осталась.
Так или иначе половина того, что упоминает автор, для меня дико неактуальна. Нет особой разницы, найду ли я класс за четверть секунды или за половину, главное, чтобы глазам было не больно и палитра красивая была.
Кстати, на примерах, которые показал автор, я наоборот с более цветастой темой куда быстрее нашла, что опять же, полагаю, потому, что для меня основная роль в цветах это разделение токенов.
Вообще и правда поймал себя недавно на мысли, что у меня глаза ужасно устают от ярких и цветастых тем. Переключился на монохромный цвет: ключевые слова выделяются жирным и курсивом, значения переменных и литералы — мягким оранжевым.
Специально залогинился, чтобы поставить стрелочку вниз, ибо название статьи - слишком кричащее для содержания, а тема - слишком субъективная
Кармы не хватило, ругаюсь буквами
Так что да, к сожалению, невозможно просто выделить всё. Приходится принимать решения: что важнее, что менее важно. Что должно выделяться, а что нет
Неужели в этих прогах, типо notepad ++, не реализовали прямо на интерфейсе пару кнопок для ручного включения подсветки констант, переменных или чего там еще по отдельности?
тыкнул кнопку — подсветка констант отключилась, и т.д.
Plugin 'Alabaster Themes' (version '1.0.93') is not compatible with the current version of the IDE, because it requires build 243.* or older but the current build is PY-252.25557.130
Стало интересно попробовать на pycharm, но чет не вышло :(
Это конечно все вкусовщина. Для себя определил правило что цвет меняется в тех областях где одно и то же слово имеет разный семантический смысл.
For имеет разный смысл как часть кода строки или комментария. Значит один цвет для всего кода. Второй цвет для строк. Третий для комментариев.
Плюс использую выделение жирным или курсивом в некоторых местах вместо цвета.
Скрытый текст
Чем занимается пользователь VSCode 90% времени? Приводит VSCode к состоянию IDE от JetBrains из коробки.
Edit++ -- всё устраивает, и подсветка синтаксиса, и автодополнение...
Почти ИИ,только сам настраивать ещё можешь, в простых текстовых файлах..
А ещё Edit++ умеет в sftp и git тоже... А мне больше и не нужно. Зато Edit++ летает по сравнению с этими вашими эклипсами .. тьфу....
У придумывания своей темы есть один минус - потом когда видишь код в стандартных темах, мозг сложнее его воспринимает. Поэтому я предпочитаю взять что-то стандартное, например тему от GitHub. Она не раскрашена как новогодняя ёлка. При желании что-то незначительно поменять, например текст (строки) на зелёный. Что вообще здравая идея, т.к. зелёный один из наиболее приятных для глаз и успокаивающих цветов. Даже глаза различают больше зелёных оттенков, чем других. Поэтому удивительно смотреть на темы, где зелёного нет вообще.
Подсветка - вкусовщина. Я вот не перевариваю красный/белый цвет кода, но это лично мои предпочтения, мне так удобнее. Пробовал штук 10 разных оформлений, выбрал чтобы глаза не уставали и были видны структуры языка. Кто попытается навязать мне другую схему, пойдёт лесом, какой бы модной она не была.
Вы неправильно используете подсветку кода.
Подсветка нужна чтобы взглянув на 1 выражение быстро найти ВСЕ части выражения.
Отдельно для каждого выражения.
Функции в целом или даже файлы подсветкой не определяются. Для этого используют форматирование и отступы.
В рамках одного выражения до 7 цветов нормально, так как их смысл не в том, чтобы быстро по цвету находить что-то (например, строку), а чтобы цвета помогли мозгу быстро разбить выражение на части. Отделить разные части callchain, аргументы от имени функции, await от const и так далее.
И у вас там еще одна ошибка - слишком светлый фон.
Кажется мы начали забывать, но автор оригинального поста даже есть на хабре — Никита Прокопов @tonsky
Вообще мне нужна подсветка для разграничения конструкций, где что кончается, без подсветки все выглядит жестоким монолитом.
Везде где можно, пользуюсь темой catppuccin tokyonight в вариантах night/day для темного и светлого оформления соответственно.
ИМХО, намного более полезным выглядит подобное решение, с затенением всего вне текущего контекста курсора
Скрытый текст
Безумие новогодней елки, значит? 🤭
Работаю только со светлой темой. Никак не могу перейти на тёмную. Тёмная тема меня угнетает, а светлая, наоборот, бодрит. На подсветку вообще не обращал внимания. Всегда ставлю стандартную светлую на Rider, и она меня устраивает. После прочтения статьи попробую провести пару экспериментов и оценить удобство.
самая лучшая расцветка - дефолтная. Не тратьте время на чепуху
Фиолетово-чёрный: https://www.youtube.com/watch?v=cN_dy10zBug )
Что-то я поставил и у меня подсвечивается явно больше чем надо. Зачем, например, подсветка total_time_remaining там, где она не обьявляется?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мне жаль, но вы используете подсветку кода неправильно