Комментарии 44
Вам, возможно, будет интересно почитать и другие статьи на тему [Язык_программирования] Style Guide / Coding Conventions.
А самый крутой гайд, имхо, в Python. Он там в официальной документации (перевод).
А самый крутой гайд, имхо, в Python. Он там в официальной документации (перевод).
Берем любой Style Guide/Coding Conventions, устанавливаем профиль code style в своей IDE (пример). После его установки — достаточно выделить весь код и запустить Reformat Code.
Можно сделать свой профиль, и использовать его для разработки, а для загрузки в git использовать code style, принятый в организации/на проекте.
Или, если не нужно использовать форматирование на отдельных участках согласно общему профилю — см. здесь.
Можно сделать свой профиль, и использовать его для разработки, а для загрузки в git использовать code style, принятый в организации/на проекте.
Или, если не нужно использовать форматирование на отдельных участках согласно общему профилю — см. здесь.
Можно просто использовать любой style guide, например, Standard
Можно подключить правила к IDE или запускать линтер локально или автоматически при деплое.
Почти со всеми приведенными примерами согласен. Ещё для большей наглядности стараюсь сложные условия разбивать на ряд простых. Тогда за счёт имени константы ещё и самодокументирование идёт. В одном же условии как ни форматируй — каша.
Ещё, чтобы не напороться на ошибки с приоритетами и просто для наглядности, условия в тернарных операторах помещаю в скобки:
ну и, кстати, в return ничего не вычисляю — отлаживать потом неудобно. Создаю переменную result и её возвращаю.
Можно подключить правила к IDE или запускать линтер локально или автоматически при деплое.
Почти со всеми приведенными примерами согласен. Ещё для большей наглядности стараюсь сложные условия разбивать на ряд простых. Тогда за счёт имени константы ещё и самодокументирование идёт. В одном же условии как ни форматируй — каша.
const tresholdOverflow = value >= someThreshold
const properType = type === someType1 || type === someType2
if (tresholdOverflow && properType ) {
do something
}Ещё, чтобы не напороться на ошибки с приоритетами и просто для наглядности, условия в тернарных операторах помещаю в скобки:
return (a < b) ? a : bну и, кстати, в return ничего не вычисляю — отлаживать потом неудобно. Создаю переменную result и её возвращаю.
Некоторые кодстайлы запрещают такие почти не используемые переменные
Константы, не переменные. Ну, вспомогательные инструменты ведь нужны для улучшения жизни, а не для того, чтобы становиться их рабами и бездумно под них подстраиваться, не так ли? Мне кажется, подход с разделением вычислений на ряд констант приближает код к такому модному нынче функциональному подходу, упрощает отладку и понимание.
If/else выглядит несимметрично и объяснения этому не вижу. Вообще ожидал подробного объяснения по каждому пункту
Если полей в объекте немого и строка не превышает нужную ширину, то отделяйте поля пробелом.
а потом надо добавить еще полей и коммит расстягивается до бескононечности. По похожей причине рекомендуется в if всегда ставить фигурные скобки даже если всего одна строчка после него
Длина строки не должна превышать ширину туннеля прямого взгляда.
А «ширина туннеля прямого взгляда» — это сколько?
Нейропсихология, формирование связей…
Лично я ожидал чуть больше, чем просто описание своего любимого кодстайла.
Например, почему два пробела лучше четырех с точки зрения формирования тех же связей?
Лично я ожидал чуть больше, чем просто описание своего любимого кодстайла.
Например, почему два пробела лучше четырех с точки зрения формирования тех же связей?
Так код более компактный и удобнее читается.
Это вкусовщина и голословные заявления. Если уж мы погружаемся в нейропсихологию, то нужно чуть больше доказательств, чем «я художник, я так вижу»
Опять же, если уж говорить о компактности и экономии места, то при импорте пробелы внутри объекта излишни, разве не так?
Опять же, если уж говорить о компактности и экономии места, то при импорте пробелы внутри объекта излишни, разве не так?
При использовании двух пробелов общая ширина строк меньше чем при четырех пробелах. Значит фокус взгляда будет сдвигаться меньше и реже, что положительно скажется на процессах анализирования.
Еще раз: это вкусовщина, подтвержденная только голословными утверждениями. С тем же успехом я могу возразить, что два пробела — слишком мало, как как мозг будет с трудом анализировать разницу между уровнями вложенности. И что оптимальным вариантом будет… три (!) пробела. Никаких исследований, подтверждающих чью-либо правоту нет. Нет даже обоснованных гипотез.
PS Кстати, нежно люблю табы в качестве отступов, потому что их как раз можно настроить на любую ширину каждому человеку в его любимом редакторе. Жаль, что все кодстайлы предписывают пробелы.
PS Кстати, нежно люблю табы в качестве отступов, потому что их как раз можно настроить на любую ширину каждому человеку в его любимом редакторе. Жаль, что все кодстайлы предписывают пробелы.
Сам всегда и пользовался два пробела. Но раньше все использовали четыре равные табу. Недавно понял что два пробела это от нашего кода с большой вложенностью. Так что хорошо ли это уже сомневаюсь.
Если говорить о практическом применении, всегда лучше взять готовый популярный и просто его придерживаться. Какой именно значения не имеет. Обычно все вменяемые.
Невменяемые получаются когда при старте проекта начинают создавать стайл с нуля, потом оказывается то это неудобно и то нехорошо.
Из явных просчетов которые встречались отсутствие запятых после последнего свойства объекта, выравнивание значений свойсв отступами, наличие противоречивых правил.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Согласен, Prettier давным-давно закрыл все вопросы касательно код-стайла, не понимаю что тут можно ещё обсуждать.
Prettier.io безусловно очень удобен для многих программистов. Но я категорически не использую притеры, автокорректоры, форматтеры и подобное им. Весь код я пишу руками, вплоть до последнего символа, чтобы держать мой мозг в тонусе, что в свою очередь сильно ускоряет профессиональный рост.
А как расстановка отступов вручную помогает держать мозг в тонусе? Это монотонная работа которую проще полностью делегировать компьютеру: prettier.io/docs/en/why-prettier.html
Примерно так же как гаммы и арпеджио помогают музыкантам
Это скорее про печать 10 пальцами вслепую. Тратить время на форматирование кода вручную довольно странное занятие. Ведь в конце все равно придется пройтись по коду автоформаттером, если в проекте принято использовать такие инструменты.
Вот согласен, если 1-2 разработчика на проекте, то ручное форматирование действительно развивает внимательность и концентрацию, учит уделять внимание каждому символу, вырабатывает самодисциплину. Первые 8 лет в разработке писал код исключительно в блокноте, без IDE и линтеров, и научился делать это достаточно красиво… А потом изобрели Eslint, и постепенно начал понимать его удобство, особенно при расширении команды. А уж в последние годы, когда появился Prettier, больше и не думаю об этом. Но опыт был полезный, сформированные тогда навыки помогают и в рефакторинге, и в код-ревью.
Думаю, рекомендовал бы юниорам тоже практиковаться без IDE с форматтерами и подсказками — это также заставляет думать о грамотной организации кода по файлам, сокращении схем нормализации и минимальном пути по пробросу данных (в те времена мне встречалось много кода на php, где приходилось открывать более 10 файлов, чтобы понять, что именно передано в функцию). Сейчас с господством IDE это снова почти становится проблемой, так как при наличии интеллектуальных подсказок можно фактически не уделять времени грамотному проектированию. Но не нужно.
Кстати, музыкант, и играю гаммы — это действительно полезно)
Думаю, рекомендовал бы юниорам тоже практиковаться без IDE с форматтерами и подсказками — это также заставляет думать о грамотной организации кода по файлам, сокращении схем нормализации и минимальном пути по пробросу данных (в те времена мне встречалось много кода на php, где приходилось открывать более 10 файлов, чтобы понять, что именно передано в функцию). Сейчас с господством IDE это снова почти становится проблемой, так как при наличии интеллектуальных подсказок можно фактически не уделять времени грамотному проектированию. Но не нужно.
Кстати, музыкант, и играю гаммы — это действительно полезно)
Речь не о "многих программистах". Речь об унификации стиля в команде из 10+ программистов. И не важно, синьор ты или мимо проходил.
Это ведь не единственное решение, можно использовать и линтер.
Линтер не является заметной форматтеру. На эти грабли уже много раз наступали. Оба инструмента хорошо дополняют друг друга.
Если получится добиться нормальной работы обеих в связки. У нас вот на фронте prettier отключили, потому что конфликтовал по правилам с eslint c typescript плагином.
А я себе именно такой вариант настроил, например. Отдав в prettier всё по части переносов и тому подобных вещей, и запретив их в eslint-typescript. Причём, если не ошибаюсь, в доках prettier даже расписано, что там отключать.
Так-то естественно, что если два разных инструмента будут форсить в одних и тех же строчках разные правила — это ничего хорошего не даст.
Так-то естественно, что если два разных инструмента будут форсить в одних и тех же строчках разные правила — это ничего хорошего не даст.
НЛО прилетело и опубликовало эту надпись здесь
Поскольку почти по каждому из стилевых правил можно спорить всей командой неделями до хрипоты, то на самом деле хорошее решение делается совсем иначе (не через споры о стайлгайде):
1) Берем вменяемые общие правила. Они совсем не обязаны быть идеальными, просто плюс-минус приемлемыми. Про prettier уже сказали.
2) Вешаем применение этих правил на коммит-хуки.
3) ?????
4) Те, кого не устраивают эти правила — вольны в своих IDE цеплять другие правила и форматировать код (на время редактирования) так, как им удобно. В VCS всё равно будет попадать единое форматирование. Короче, PROFIT.
1) Берем вменяемые общие правила. Они совсем не обязаны быть идеальными, просто плюс-минус приемлемыми. Про prettier уже сказали.
2) Вешаем применение этих правил на коммит-хуки.
3) ?????
4) Те, кого не устраивают эти правила — вольны в своих IDE цеплять другие правила и форматировать код (на время редактирования) так, как им удобно. В VCS всё равно будет попадать единое форматирование. Короче, PROFIT.
НЛО прилетело и опубликовало эту надпись здесь
Тут можно без else, почитайте про early return: habr.com/ru/post/348074
В такой конструкции я бы не использовал else, однако если хотите симметричность и один return, то можете сделать так:
let value
if (condition) {
value = ...your_code...
} else {
value = ...your_code...
}
return value
В идеале у каждой строчки кода должен быть лишь один повод для изменения. Но компактный код читать проще, чем написанный вразрядку. Поэтому на практике приходится искать баланс. Остальные правила поддаются формализации.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новый взгляд на code style