Интересно как это происходит: у вас отсутствует code review как обязательный этап? Ну, то есть чувак написал транслитом. Ты возвращаешь ему — он не в состоянии исправить или в следующий раз история повторяется? Тогда он просто идиот и я не понимаю о каком успехе проекта с идиотами можно говорить.В реальности проекты живут на коде с разными стилями фигурных скобок, с костылями и переменными на транслите. Влияние стиля кодинга на успех проекта не стоит преувеличивать.
Если программирование не связано с наукоёмкой областью, то это практически не даёт ему никаких преимуществ. Пусть идёт работать аналитеГом, в нашей профессии важны другие качества.У меня паренек один, отличный математик и алгоритмист из пригорода
В этом случае он будет отключен как-нибудь, да так и оставлен ;-)Ну, и возможность быстро отключить хук для экстренных случаев.
Не, надо хитрее, с какой-нибудь опцией можно пушить, пропуская хуки, но будет письмо на dev о том, что был not verified push или как-то так.В этом случае он будет отключен как-нибудь, да так и оставлен ;-)
добавлю недостающую часть манифестаАрхитектура важнее, чем стиль именования переменных. Постановка задачи важнее, чем архитектура. Анализ бизнес-логики важнее, чем постановка задачи.
Вот так у меня в работе расставлены приоритеты.
Важнее не обозначает что этого не должно быть. Для меня не важно - это стандартное правило в CI на проверку CS, если CS всё же важен, то нужно уделить время и обсудить стиль и внести правки в стандартное правило. наличие проверки CS вообще не должно обсуждаться. Ревьювер должен проверять код, а не стиль, стиль пускай проверяет автоматизация.То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.