Сегодняшняя тема - часть Сonfiguration Management'а - code style.
Configuration management - это в первую очередь, чтобы среды разработки у разработчиков были схожие. Согласитесь, что если все разработчки программируют в одной IDE под одной операционной системой, с одинаковыми настройками среды - намного проще решать общие баги. Не надо думать, почему скрипт сборки работает у разработчика под ubuntu, а у разработчика на СentOS проект не собирается (докер вам в помощь).

Так вот, про code style.
В проектах командам рекомендуются использовать общие правила по написанию кода. Естесственно используются для этого автоматические тулзы. Обычно их называют линтерами (например, eslint). Общие правила для команды выбираются обычно следующим способом.

Кому-то назначается таска в джире на настройку общего конфига. Разработчик пишет правила, форматирует проект, завершает таску, правила и отформатированный проект попадают в репозиторий. Следующие ПРы других разработчиков вызывает маты , потому что столько конфликтов разработчики мёрджить не планировали. А когда начинаются проблемы с конфликтами, то начинаются придирки к правилам. И вот тут начинается холивар на несколько дней.
Вообще обсуждение правил - достаточно тяжёлая тема, при которой даже опытные разработчики не удерживаются от перехода на личности и взаимные оскорбления. "Да я 10 проектов делал, нигде мы *I* перед интерфейсом не писали, это прошлый век, так никто не пишет больше!". "Это очень удобно писать I перед интерфейсом, удобней пользоваться поиском, а то при поиске интерфейса Product мне ещё 10 Product'ов вылезает". И это может длиться вечно.
Что важно помнить:
1) ПР с форматированием проекта должен быть сделан в конце спринта, висеть минимальное количество времени, чтобы потенциальное количество конфликтов было минимальным
2) Правила не надо обсуждать, за них надо голосовать. Есть спорные мнения по правилу - пусть каждый выскажется в течение 1 минуты без перебиваний. После этого - голосование. Пофиг насколько _опытен_ тот или иной разработчик, каков его авторитет. Настоящий профессионал знает, что спорить можно бесконечно, главное - придти к консенсусу и следовать правилам. Зачастую разработчик хочет, чтобы приняли именно *его* предложение - вот истинная причина спора. "Я работаю 7 лет, как можно принять предложение не моё, а вот этого джуна?!" - вот обычно что скрывается за _аргументированным_ обоснованием того или иного правила.
3) Основные сложности при использовании общих правил написания кода - communication issues, то есть межличностные