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

Ручной способ можно описать примерно так: у команды есть какая-то договоренность по стилю написания и даже возможно она записана в общем для команды “источнике знаний”, для того чтобы в последующих моментах можно было на это ссылаться. Дальше, после написания кода одним из участников команды, начинается проверка его в ручном режиме: открываются изменения, каждый участник команды проверяет этот код на соответствие командной договоренности по стилю написания и пишет замечания, которые автор должен будет исправить. Не сложно понять, что на одно изменение тратиться время каждого участника команды.

Для автоматического используются статические анализаторы, которые представляют из себя программы, проверяющие код на соответствие каким-либо правилам. Весь процесс выглядит примерно так: разработчик делает изменения, загружает их в систему сборки, которая запускает разные проверки и если все хорошо, то изменения проходят дальше, а если нет - то сборка завершается с ошибками, которые в последствии нужно исправить, чтобы изменения смогли попасть в основную кодовую базу. На это тратится только время одного разработчика.

Для того, чтобы не тратить время на удовлетворение статического анализатора кода, придумали еще один вид программ, который форматирует код по таким правилам, которые смогут удовлетворить анализатор кода без участия человека. Такой инструмент называется форматер кода (code formatter). В таком случае можно писать код как угодно, но после пропуска его через такую программу, все становится одинаковым и узнаваемым.

Инструменты для форматирования кода тоже можно разделить на два типа: в которых можно настраивать правила форматирования и в которых нельзя. Все они решают проблему написания и приведения кода к одному стилю, но проблему чтения решает только один.

Почему плохо иметь настраиваемый инструмент для форматирования кода? Можно разобрать на следующем примере. Допустим есть две команды, в каждой из которых приняли свой неповторимый стиль кодирования. Участники команд настроили анализаторы и форматеры кода на свои правила и живут - горя не знают. Все классно, но до тех пор, пока один из разработчиков одной команды не решает помочь разработчикам другой. Проблем с написанием нет, но теперь появилась проблема со чтением. Ведь когда привыкаешь к одному стилю форматирования, то другой кажется чем-то инородным и раздражающим. Тут и начинает проявляться раздражённость, недосып и плохое настроение, которое приводит к плохим решениям и снижению продуктивности. В этом случае, можно решить проблему принятием единого стиля форматирования на всю компанию. Уже лучше, но все ещё полумера. Разработчик может быть активным участником проектов с открытым исходным кодом, где у каждого проекта свой неповторимый стиль и тут снова появляется раздражение и вот это всё.

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