Форматирование кода в Java всегда было темой обсуждения среди разработчиков. Многочисленные инструменты предлагают свои решения, но ни один из них не кажется идеальным. Так, возникает вопрос: есть ли форматтер, который действительно отвечает всем нашим требованиям?
В новом переводе от команды Spring АйО рассмотрены популярные инструменты, их плюсы и минусы, а также рассуждения на тему: может ли Java-экосистема предложить достойный форматтер?
Я не нашел ни одного форматтера для Java, который бы мне понравился. И поверьте, я искал.

Давайте обсудим, потому что я действительно хочу изменить свое мнение.
Моя история с форматтерами кода
Для начала немного предыстории. Не стесняйтесь пропустить эту часть, если хотите перейти к главному.
Когда я был подростком, мы с другом работали над проектом для хобби. Мы еще не знали о системах контроля версий, поэтому каждый день в школе обменивались дискетами с исходным кодом, который я вручную интегрировал дома. Часть этого процесса включала исправление пробелов, отступов и заглавных букв. Мой друг был неплохим программистом, но его код казался мне, как перфекционисту, неопрятным. Исправление этого давало мне ложное ощущение продуктивности, и, вероятно, именно тогда в моем сознании возникла токсичная мысль: хороший программист настолько точен и заботится о своем ремесле, что ему не нужен автоматический форматтер.
Годы спустя мне пришлось проводить код-ревью с неопытным коллегой. Я не смог читать его код, потому что он был плохо отформатирован. Я не преувеличиваю, это было действительно нечитабельно. Тогда я пришел к токсичной мысли: этот человек явно не заботится о своем ремесле. Я отправил его исправлять форматирование, и затем мы продолжили ревью.
Еще несколько лет спустя токсичная мысль укоренилась еще глубже, когда я начал работать в известной голландской компании в команде, где использование форматтера было обязательным. Форматтером по умолчанию был «плохо настроенный Eclipse», и вместо того, чтобы сохранять конфигурацию в системе контроля версий, она вручную копировалась на каждую рабочую станцию. Я спросил у коллеги, что он думает по поводу этого форматтера. Он сказал: «Мне нравится, что он последователен в читаемости». Я ответил: «Ты имеешь в виду последователен в нечитабельности». Он: «Ну… да». Иногда я пытался сделать код более читаемым вручную, но каждый раз, когда кто-то редактировал тот же файл, Eclipse с удовольствием переформатировал все обратно. Тогда я попробовал изменить конфигурацию. Все подумали, что это хорошая идея, но никто не захотел перенастраивать свой Eclipse, и на этом все закончилось.
Вот как, по моим воспоминаниям, это выглядело (преувеличено для драматического эффекта):
ExpectedException
.when(() -> EqualsVerifier.forClass(Foo.class).suppress(Warning.NONFINAL_FIELDS)
.withPrefabValues(List.class, Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList()).verify()).assertFailure()
.assertMessageContains("something");Переломный момент для меня наступил спустя несколько лет, когда я работал над проектом на Scala и познакомился с Scalafmt. Один коллега настоял на его использовании, и я неохотно согласился. Это был первый форматтер, который действительно работал и работал хорошо. Конфигурация могла храниться в git вместе с проектом, и он хорошо интегрировался со всеми инструментами. Более того, я обнаружил, что он улавливал несоответствия, которые я сам допускал в коде. Видимо, теперь я недостаточно заботился о своем ремесле! Я заметил, что он улучшил код моих коллег. И он мог бы решить ту проблему с код-ревью с помощью всего одной кнопки.
Это послужило концом моих токсичных мыслей о форматировании: мое мнение изменилось.
Я решил внедрить форматтер в EqualsVerifier. Я попробовал несколько вариантов, начал с google-java-format, перешел на Prettier Java и пришел к смелому выводу, что все инструменты форматирования для Java неудовлетворительны.
Так что же я хочу от форматтера?
В основном, я хочу то, что есть у форматтеров в других языковых экосистемах, таких как Scala, Rust и Go. А именно:
