Comments 57
ИМХО: все равно, какой code style, лишь бы он был и все его придерживались.
Делом бы этим людям заняться.
По-моему этот вопрос яйца выеденного не стоит с момента распространения линтеров. Как избавиться от холиваров в 3 шага:
тимлид устанавливает правила
тимлид подготавливает тулинг: настройки линтера, прогон линтера в CI/CD, файл с настройками IDE для новичков
любое изменение правил идет через общее обсуждение с аргументами на периодических собраниях. Не каждый день и не с "а у нас так всегда писали", а именно с фактурой, почему так лучше или хуже
По момему опыту проблемы бывают из-за анемичного тимлида, который забил на первые 2 пункта. Логично, что если правил нет, то каждый норовит их установить - потому что жить без правил таки тяжело и все это понимают.
тимлид устанавливает правила
Ну да, тимлиду ведь больше нечем заняться, как решать, надо всегда ставить скобочки или не надо или не всегда. Других-то проблем у проекта нет.
тимлиду ведь больше нечем заняться, как решать, надо всегда ставить скобочки или не надо или не всегда
Ну вот из-за такой философии мы в 2025 году продолжаем на серьезных щщах обсуждать эти вопросы в паблике. Генералам как-то не лень придумывать уставы, королям как-то не лень придумывать законы, всяким ГИПам как-то не лень создавать дорожные карты целых проектов. А у тимлида очередного джейсоноперекладчика ну конечно же есть Проблемы Поважнее.
Жаль не могу плюсануть!
Да-да. Тимлид сидит, в потолок плюёт и планирует, как его корабли будут бороздить просторы Вселенной, а заниматься таким приземлённым делом ему попросту лень.
А то, что на проекте из-за горы техдолга разработчики не могут уже новый функционал писать и это всё надо разгребать, внятной системы логирования и обработки ошибок нет и любой баг становится приключением, новые фичи от заказчиков надо спроектировать и оценить, кроссплатформенность внедрить, CI починить наконец, ревью накопившихся МР сделать, при этом постоянно сваливается какая-то текучка типа составить тех. отчёт или сделать очередной релиз или настроить что-то в соотв. с изменившейся инфраструктурой, и каждый день практически тебе пишут подопечные с вопросами, в которые надо каждый раз вникать, быть в курсе, что они делают, чтобы не наворотили всяких конфликтов, на зависания сборки жалуются - этим тоже надо заняться, чтобы им разрабатывалось нормально, а ещё и уходит иногда кто-то и надо новых сотрудников подбирать и в курс дела вводить, с другими командами и проектами взаимодействовать, и всё это одновременно. И изучать, изучать, изучать - что твои разрабы нового применили - изучать, где твой проект крутится - изучать, какие можно использовать технологии и подходы для новой задачи - изучать, что там в новых версиях фрэймворков нафигачили - изучать.
Но это всё мелочи, куда важнее раз и навсегда решить вопрос со скобочками!
Вопрос кодстайла ничем не хуже и не лучше, чем вопрос техдолга и далее по тексту. Можете слезу у меня не давить своими историями - дважды в тимлидах ходил, все это прекрасно знаю. Плюс я не говоорю, что нужно бросить все и линтеры бегом настраивать. Но если тимлид этим заниматься не будет, то кто? Джуны, уборщица, дворняжка местная?
Дело не в хуже/лучше, дело в приоритетности. Если будут со скобочками/без них писать или там private член не туда засунут - это ущемит чью-то чувствительную душу. Не страшно - в будущем можно будет автоматизированно исправить. Если корневой тех. долг не решить - разрабы получат головную боль в борьбе с ним, а компания и проект потеряет человеко-часы/дни/недели.
Можете слезу у меня не давить своими историями - дважды в тимлидах ходил, все это прекрасно знаю.
Могу только позавидовать вам и вашим проектам и командам. Уверен, вы там всё грамотно настроили, разобрались со всеми серьёзными проблемами и всячески облегчили жизнь своим подопечным.
Если смотреть на разработку и командную работу, как на набор бесконечных пожаров в условии дефицита ресурсов (руки, время), то да - всегда будет что-то более приоритетное, вопросов нет. Но не надо из-за этого делать выводы о других проектах.
Если же есть хоть какая-то перспектива на разгребание техдолга, то внедрение инструментов качества кода, таких как линтеры, форматеры и т.д. - хороший шаг для начала. Затраты на эти изменения низкие, а пользу начинает приносить быстро - код становится более читаемым и упрощается код-ревью (больше смотрим на суть, а не на скобочки). И вот уже у Вашей команды больше времени и сил на что-то посерьезнее.
Стратегию внедрения Вы сами можете продумать, учитывая реалии проекта. Например, можно прописать исключения на ту часть проекта, которая в данный момент не разрабатывается активно. И постепенно расширять область, где правила работают в полном объеме.
Код надо держать в здоровом состоянии, тогда над проектом будет легче работать
Не могу с вами согласиться. На самом деле я удивлён, что такое надо объяснять вообще. Если бы я работал под управлением тимлида, который при наличии более серьёзных проблем стал бы тратить много времени на вещи наподобие создания code style (а затраты на это ни разу не низкие, если основательно браться), то я бы подошёл к нему с вопросами, а зачем собственно он этим сейчас занимается и не лучше ли сперва сконцентрироваться, допустим, на сборке и CI, на которые его подопечные постоянно жалуются.
Опять же, вы говорите про качество кода, линтеры, форматеры. Всё перечисленное и пресловутый code style (аля одинаковые скобочки и отступы) - это всё разные вещи, хотя и, безусловно, в той или иной степени связанные.
А теперь история из жизни.
Я пришёл на проект где толпа джунов не могла зарелизиться, потому что на ревью спорили за стиль форматирования, способ проброса ошибок и т.д. и т.п. За всё спорили. Я своей авторитарной тимлидской рукой сказал "вот так делайте, а если думаете, что нужно по другому, потом обсудим". И разработка пошла. Среднее время прохождения ПР снизилось с 2-х недель до 2-х дней.
Я так же как и автор считаю, что пофиг какой стиль. Главное чтобы был, а там, либо привыкнем, либо передоговоримся.
Ну, у меня не джуны, а вполне крутые спецы. Они иногда поспорить тоже любят, но по делу, а не по пустякам : )
А крутым спецам даже тимлид не нужен, они сами справляются. Ладно, тимлид им нужен, чтобы на него спихнуть неинтересную управленческую работу.
У спецов вполне может быть ситуация: "я с вами не согласен, но принимают ваше решение". Ибо они понимают, что рубиться весело, но проект нужно двигать. При этом решение фиксируют в ADR или прочих DR, с альтернативами, рисками и т.п., чтобы в случае чего можно вернуться к вопросу понять почему так решили. Т.е. рубилово - это тоже работа и в результате она имеет артефакт. А не так, что поговорили и забыли.
А ещё можно поступить точно так же, но проще - совершенно произвольно запретить на код ревью поднимать темы код стиля и сначало мягко объяснить нарушителем запрета, второй раз жёстко высушить и что то там ещё, а третий последний.
И внезапно люди научаются жить без линтеров, читать код в любом стиле и писать так как душе нравится. Оставить можно только совсем базовые принципы именования и то сделать упор, но то как не надо именовать, но не навязывать жёстко как надо.
Консистентнгсть это миф, у вас в коде всегда смесь, ваш код, стандартная библиотека, фрэймворк, и поверх ещё чужие библиотеки и каждый в своем стиле и нужно часто все это в одном месте/функции. И как то все живут и не жужат, а тут видители колега совсем берега потерял в моей песочнице ссыт не по-моему уставу.
Встречалось что в кодстайле утверждены "висящие запятые"?
var obj = new {
field1 = "test",
field2 = 3,
};
Да, встречалось. Не стал добавлять это в статью, но так же в одних проектах обязательно оставлять запятые, в других - обязательно не оставлять. Тоже принципиальной разницы нет, на мой взгляд.
Это связано с тем, что некоторые автоформатировщики когда парсят код не знают в какой момент писать в одну строку, а в какой момент в несколько строк. И в тех языках, где разрешены висячие запятые, в большинстве случаев определение идёт по запятой в конце. Так исторически сложилось. Есть запятая - блок будет раскидан по отдельным строкам, нет запятой - блок будет выстроен в одну строку
Не только. Если есть "висячие" запятые, то новая строка в таком переислении/структуре - это плюс одна строка с изменением (+1). Если нет, то надо добавить запятую (одна строка изменений -1+1) и еще одна новая строка. Банально проще ревьювить вариант с висячими запятыми.
И да, я понимаю что это "мелочь" и "завем вообще об этом думать?", но для меня такие вот "мелочи" во многом и определяют удобство код стайла.
Поддерживаю. В Java так в enum можно добавлять с запятой в конце. Удобно когда новые значения добавляешь - только плюс одна строчка в диффе. И когда удалить хочешь - тоже только её удаляешь. Я во всех enum стараюсь её использовать.
Я деталей подхода написания Java кода не знаю, так как не пишу на нём. А вот на Zig, Kotlin, Go, Lua, именно так и происходит. Там специально оставляют запятую вконце, чтобы автоформатировщик выставил аргументы по строчно, где это нужно. И это удобно
Ха, как вам такое?
function get_some (
p_foo in varchar2_nn
,p_bar in number_nn
,p_is_enable in boolean default true
) return some_t;
А как вам запятые в начале строки? (Tsql)
select
column
, column2
fromМне всё равно, какой у вас код-стайл
, лишь бы он был!
Почему название интерфейса с I начинается? Может быть и не нужен тогда интерфейс?
У нас так принято
Interface names start with a capital
I.
Как выглядят мои почти 20 лет опыта в разработке:
Первые пять лет ты весь такой молодой и дерзкий, готовый жизнь положить за один из подходов. Сторонники противоположного за это считают тебя неадекватом.
Потом ещё пять лет ты весь такой прошаренный, защищаешь другой подход (противоположный). За это те, кто остался держаться за прошлое мнение, считают тебя предателем.
Потом года после десятого становится пофиг на холивары. Готов жить с любым подходом, лишь бы на мозги не капали. За это и те, и другие катят на тебя бочки и считают бесхребетным планктоном без своего мнения.
А через сколько лет начинаешь отстаивать именно тот подход, которой объективно лучше других подходит в каждом конкретном случае?
Или люди столько не живут?
Что есть объективность? Какие критерии? Вопрос код стайла это почти всегда вкусовщина. "Скобки переносить или нет", "2 или 4 пробела отступ", "выравнивать присваивания по вертикали или нет" и т.д.
Как по мне, то для каждого языка есть полезные правила, но они не зависят от "случая".
Ну для примера: если большинство в команде работает на 23‘-27‘ fhd мониторах, ставить ограничение в 160-180 символов в строке (у тимлида 4к на пол стены) - объективно выходит за рамки вкусовщины.
В общем, объективность - это когда есть способ измерить потенциальную пользу/вред тех или иных изменений в код-стайл. Остальное действительно вкусовщина. Но и таких правил, которые объективно влияют на удобство - тоже хватает. И тут уже нужно смотреть насколько в конкретной команде и в конкретном проекте будет лучше использовать то или другое.
Да пожалуйста, вот вам контраример: у меня сейчас как раз команда, которая работает на 24' 2к мониторах (корпоративный стандарт). По вашей логике "объективно" (ни разу) можно ставить 160 символов в строку. По моей (тоже не объективно, но я-то и не претендую) - 120.
Причин масса: 2 панели IDE, трехстророннее сравнение, вертикальная консоль сбоку. Да в целом пусть даже у кого-то 18й шрифт или масштаб 200%, не важно. Важно что бы было удобно не только "тимлиду с 4к монитором на пол стены", а всем или хотя бы большинству (80%+).
Так это не контрпример) Оба последних предложения в наших комментариях являются прямыми аналогами.
Я тоже считаю, что основной критерий объективности пользы или вреда каких-либо изменений - это мнение коллективного большинства. Мой пример лишь подсвечивал, что не все правила могут быть лишь вкусовщиной и никак не зависить от случая.
Я уже на третьей стадии перестал верить в существование "подхода, которой объективно лучше других". Есть ограничения по времени и ресурсам, есть ограничения конкретных технологий и фреймворков, есть объективные требования (типа стандартов) и субъективные хотелки заказчика, есть хтоничное легаси и веяния постоянно меняющейся моды, да много ещё какие звёзды на небе влияют на разработку. Сидишь себе такой в болоте сплошного дзена и смотришь, как зажигаются и гаснут пердаки у спорящих, молоток какого цвета лучше всего подходит для забивания гвоздей в этой фазе луны.
Меня больше поразило, что на ревью тратят время на кодстайл, как будто линтеров форматтеров не существует. И что 10 проектов за 7 лет - возможно у меня сдвиг восприятия, но казалось, что с галерного типа разработки обычно сбегают в продукт с возрастом))
Про интерфейс в одном файле я удивлен. Думал так вообще не делают.
Автор познал дзен?
А как насчёт проекта, где фигурная скобка, с которой начинается тело метода, находится на той же строке, что и названием метода?
Или проекта, в котором названия методов начинаются с маленькой буквы?
Ну или там, не знаю, где табами отступы надо делать? ))
Давайте без совсем уж жести :)
А если приходится совмещать C# и Rust (где первые два пункта как раз входят в стиль кода), то на все правила смотришь как-то с бо́льшим фатализмом.
В Шарпе принято фигурную скобку на новой строке ставить, в Джаве на той же на той же.
Фигурная скобка на той же строке позволяет экономить вертикальное пространство, которое почти в два раза дефицитнее горизонтального. Сам иногда так делаю, когда пишу «одностраничники» в петпроекте или на литкоде.
А вот в этом вашем пхп есть psr12
{} обязательны всегда, потому что после нескольких правок обнаружил:
if (x > 0)
if (y > 0) z = 43; else z = 42;
МИСРу уважать надо!
А Табы меняются с возрастом...
Code style - классная вещь. Но когда он зашит в прекоммит или хотя бы в линтер. А когда тебе на ревью прилетает 50+ тредов - возникает грусть. А так да, пару месяцев на проекте чтобы глаза привыкли к коду - и единый стиль очень сильно улучшает читаемость
Вы привели эквивалентные стили..
Но есть же и дичь. Например использование выравниваний по какойто границе. Или несколько переносов строк для отделения секций (select, from, etc) в sql. Это очень шаткий стайл, который в маленький конструкциях норм а средние и большие - каша.
Всегда пишем суффикс Async для асинхронных методов
Видел у Ника Чапсеса (видеоблоггер интересный, кто не знает) ещё такой вариант.
Если есть 2 реализации синхронная и асинхронная, то добавляем Async.
Если только синхронная или только асинхронная, то без этого суффикса.
Мне всё равно, какой у вас код-стайл