Comments 44
Вам, возможно, будет интересно почитать и другие статьи на тему [Язык_программирования] Style Guide / Coding Conventions.

А самый крутой гайд, имхо, в Python. Он там в официальной документации (перевод).
Добрый день. Спасибо за совет, обязательно почитаю. Сам я начинал с рекомендаций от Airbnb.
Берем любой Style Guide/Coding Conventions, устанавливаем профиль code style в своей IDE (пример). После его установки — достаточно выделить весь код и запустить Reformat Code.

Можно сделать свой профиль, и использовать его для разработки, а для загрузки в git использовать code style, принятый в организации/на проекте.

Или, если не нужно использовать форматирование на отдельных участках согласно общему профилю — см. здесь.
Можно просто использовать любой style guide, например, Standard
Можно подключить правила к IDE или запускать линтер локально или автоматически при деплое.

Почти со всеми приведенными примерами согласен. Ещё для большей наглядности стараюсь сложные условия разбивать на ряд простых. Тогда за счёт имени константы ещё и самодокументирование идёт. В одном же условии как ни форматируй — каша.
const tresholdOverflow = value >= someThreshold
const properType = type === someType1 || type === someType2
if (tresholdOverflow && properType ) {
  do something
}


Ещё, чтобы не напороться на ошибки с приоритетами и просто для наглядности, условия в тернарных операторах помещаю в скобки:
return (a < b) ? a : b

ну и, кстати, в return ничего не вычисляю — отлаживать потом неудобно. Создаю переменную result и её возвращаю.

Некоторые кодстайлы запрещают такие почти не используемые переменные

Константы, не переменные. Ну, вспомогательные инструменты ведь нужны для улучшения жизни, а не для того, чтобы становиться их рабами и бездумно под них подстраиваться, не так ли? Мне кажется, подход с разделением вычислений на ряд констант приближает код к такому модному нынче функциональному подходу, упрощает отладку и понимание.

Из спеки языка:


let and const declarations define variables

Ну вот некоторые считаю, что конструкции типа


const result = ...;
return result;

усложняют понимание. И в целом я с ними согласен. а если отладить надо, то делаю introduce variable, отлаживаю и возвращаю как было.

If/else выглядит несимметрично и объяснения этому не вижу. Вообще ожидал подробного объяснения по каждому пункту

Добрый день. If/else я пишу так для лучшей визуализации. Напишите пункты по которым вам не хватает объяснений и вам их дам.
Если полей в объекте немого и строка не превышает нужную ширину, то отделяйте поля пробелом.

а потом надо добавить еще полей и коммит расстягивается до бескононечности. По похожей причине рекомендуется в if всегда ставить фигурные скобки даже если всего одна строчка после него
Длина строки не должна превышать ширину туннеля прямого взгляда.

А «ширина туннеля прямого взгляда» — это сколько?
Spoiler header

image


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

Нейропсихология, формирование связей…
Лично я ожидал чуть больше, чем просто описание своего любимого кодстайла.
Например, почему два пробела лучше четырех с точки зрения формирования тех же связей?
Это вкусовщина и голословные заявления. Если уж мы погружаемся в нейропсихологию, то нужно чуть больше доказательств, чем «я художник, я так вижу»
Опять же, если уж говорить о компактности и экономии места, то при импорте пробелы внутри объекта излишни, разве не так?
При использовании двух пробелов общая ширина строк меньше чем при четырех пробелах. Значит фокус взгляда будет сдвигаться меньше и реже, что положительно скажется на процессах анализирования.
Еще раз: это вкусовщина, подтвержденная только голословными утверждениями. С тем же успехом я могу возразить, что два пробела — слишком мало, как как мозг будет с трудом анализировать разницу между уровнями вложенности. И что оптимальным вариантом будет… три (!) пробела. Никаких исследований, подтверждающих чью-либо правоту нет. Нет даже обоснованных гипотез.

PS Кстати, нежно люблю табы в качестве отступов, потому что их как раз можно настроить на любую ширину каждому человеку в его любимом редакторе. Жаль, что все кодстайлы предписывают пробелы.

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


Если говорить о практическом применении, всегда лучше взять готовый популярный и просто его придерживаться. Какой именно значения не имеет. Обычно все вменяемые.


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


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

Самый лучший код-стайл — тот, который поддерживается средствами автоматического форматировани и контроля и интегрирован в девфлоу. Чтобы вопрос код-стайла на код-ревью вообще не всплывал.

Интересно, а встречал кто-нибудь рекомендацию упорядочивать функции в классе по наименованию? (например, в каком-нибудь классе python — 7 функций и желательно их упорядочить). Такое ощущение что где-то встречал, но не смог найти где…

Встречал сначала по области видимости, а внутри по имени. И мне это нравится — минимум отсебятины и максимум возможностей автоматического контроля.

Согласен, Prettier давным-давно закрыл все вопросы касательно код-стайла, не понимаю что тут можно ещё обсуждать.
Prettier.io безусловно очень удобен для многих программистов. Но я категорически не использую притеры, автокорректоры, форматтеры и подобное им. Весь код я пишу руками, вплоть до последнего символа, чтобы держать мой мозг в тонусе, что в свою очередь сильно ускоряет профессиональный рост.
А как расстановка отступов вручную помогает держать мозг в тонусе? Это монотонная работа которую проще полностью делегировать компьютеру: prettier.io/docs/en/why-prettier.html
Это скорее про печать 10 пальцами вслепую. Тратить время на форматирование кода вручную довольно странное занятие. Ведь в конце все равно придется пройтись по коду автоформаттером, если в проекте принято использовать такие инструменты.
Вот согласен, если 1-2 разработчика на проекте, то ручное форматирование действительно развивает внимательность и концентрацию, учит уделять внимание каждому символу, вырабатывает самодисциплину. Первые 8 лет в разработке писал код исключительно в блокноте, без IDE и линтеров, и научился делать это достаточно красиво… А потом изобрели Eslint, и постепенно начал понимать его удобство, особенно при расширении команды. А уж в последние годы, когда появился Prettier, больше и не думаю об этом. Но опыт был полезный, сформированные тогда навыки помогают и в рефакторинге, и в код-ревью.
Думаю, рекомендовал бы юниорам тоже практиковаться без IDE с форматтерами и подсказками — это также заставляет думать о грамотной организации кода по файлам, сокращении схем нормализации и минимальном пути по пробросу данных (в те времена мне встречалось много кода на php, где приходилось открывать более 10 файлов, чтобы понять, что именно передано в функцию). Сейчас с господством IDE это снова почти становится проблемой, так как при наличии интеллектуальных подсказок можно фактически не уделять времени грамотному проектированию. Но не нужно.
Кстати, музыкант, и играю гаммы — это действительно полезно)

Речь не о "многих программистах". Речь об унификации стиля в команде из 10+ программистов. И не важно, синьор ты или мимо проходил.

Линтер не является заметной форматтеру. На эти грабли уже много раз наступали. Оба инструмента хорошо дополняют друг друга.

Если получится добиться нормальной работы обеих в связки. У нас вот на фронте prettier отключили, потому что конфликтовал по правилам с eslint c typescript плагином.

А я себе именно такой вариант настроил, например. Отдав в prettier всё по части переносов и тому подобных вещей, и запретив их в eslint-typescript. Причём, если не ошибаюсь, в доках prettier даже расписано, что там отключать.

Так-то естественно, что если два разных инструмента будут форсить в одних и тех же строчках разные правила — это ничего хорошего не даст.
Поскольку почти по каждому из стилевых правил можно спорить всей командой неделями до хрипоты, то на самом деле хорошее решение делается совсем иначе (не через споры о стайлгайде):
1) Берем вменяемые общие правила. Они совсем не обязаны быть идеальными, просто плюс-минус приемлемыми. Про prettier уже сказали.
2) Вешаем применение этих правил на коммит-хуки.
3) ?????
4) Те, кого не устраивают эти правила — вольны в своих IDE цеплять другие правила и форматировать код (на время редактирования) так, как им удобно. В VCS всё равно будет попадать единое форматирование. Короче, PROFIT.
Вопрос к знатокам по поводу if-else:
В следующей конструкции:

if (certain_condition) {
    value1 = ...your_code...;
    return value1;
} else {
    value2 = ...your_code...;
    return value2;
}

Вы используете оператор else? С одной стороны else не нужен, так как в секции if уже есть return, кроме того так короче. С другой стороны без else код получается как бы 'несимметричный'.
В такой конструкции я бы не использовал else, однако если хотите симметричность и один return, то можете сделать так:

let value

if (condition) {
  value = ...your_code...

} else {
  value = ...your_code...
}

return value
В идеале у каждой строчки кода должен быть лишь один повод для изменения. Но компактный код читать проще, чем написанный вразрядку. Поэтому на практике приходится искать баланс. Остальные правила поддаются формализации.
Only those users with full accounts are able to leave comments. Log in, please.