Comments 21
Если "достойных" инструментов форматирования нет, значит автор высосал проблему из пальца.
P.S. кликбейтные заголовки прямо просят минус в рейтинг
Проблема всё же есть хотя бы в непопулярности форматтеров.
В Java наиболее популярным решением для проверки code-style кажется считается checkstyle. Но checkstyle не форматтер.
Результаты по поиску форматтера для Kotlin сразу два решения, которые более менее стандарты в индустрии
В Java... данная тема не пользуется популярностью
Почему в Java форматтеры не так популярны? Возможно как раз из-за качества инструментов. Сам я эту тему пока только планировал покопать, но надеюсь что вынесу что-то из обсуждения к данной статье.
На мой взгляд, дело в достаточно хороших конвенциях которые были приняты в самом начале. Все эти расположения скобок, именования классов, переменных, методов. Эти базовые конвенции закрывают 90% потребностей (причем это поведение одинаково для всех IDE). Самая конфликтная точка была tab vs space лет 10-12 назад, но как-то со временем само собой устаканилось на пробелах. Вот и получается что конфликта между форматтерами разных разработчиков практически не встречается. Ну или скажу аккуратнее, конфликтов ощутимо меньше чем в других языках.
Подозреваю, что нет такого понятия как идиоматичный java-код. Существуют идиоматичный код на kotlin, идиоматичный код на rust, идиоматичный код на typescript, идиоматичный код на scala. И для всех этих языков есть стандартные конвенции по написанию кода. А для java - нет. Даже туториалы для java на сайте оракла написаны таким образом, что мало кто использует такой стиль в коде для прода по причине плохой читаемости и error-prone (например, присваивание и проверка значения в одном и том же выражении, разнесение объявления переменной и ее инициализация, итерирование по массивам через индексы, и т.п.)
Когда появится идиоматичная java, тогда и появится тот единственный форматтер, который удовлетворит всех разрабов
Самая конфликтная точка была tab vs space лет 10-12 назад, но как-то со временем само собой устаканилось на пробелах.
Really? А я уверен, что на табуляции. Точнее на табуляции для лидирующих отступов и пробелах для всего остального.
На сегодняшний день большинство Java проектов отдают предпочтение пробелам для выравнивания кода, в то время как табуляции остаются в меньшинстве. Согласно данным по Java-проектам, оценочная доля использования табуляций составляет примерно 10-33%, тогда как оставшаяся часть проектов использует пробелы в различной конфигурации (чаще всего 4 пробела). Основная причина выбора пробелов — это консистентность отображения кода в разных редакторах и на разных платформах, что упрощает совместную разработку и улучшает читаемость кода.
форматеры может быть не такие уж и плохие, например, мне кажется достаточно продвинутой возможность в IntelliJ IDEA настроить параметры форматирования визуально редактируя образцы кода. А результат в обзоре получается не очень, скорее, потому что рассматриваемый тестовый образец достаточно сложен. По собственному опыту могу сказать, что лажают и форматеры для других языков, много раз я боролся с eslint для тайпскрипта глуша его специальными комметариями(что тоже не всегда возможно и часто создает необходимость переписывать код на менее элегантный). Форматирование даже такого "детерменированного" формата как html в интелидже может делать переносы совершенно не там, где это было бы логично, т.е. может перенести на новую строку один закрывающий тег. Есть еще такое наблюдение, что форматтилками увлекаются в большей степени там, где "стандартное" форматирование достаточно необычно, например в go где, кемел.КейсНаоборот будет выглядеть странно для пришедшего с пхп, безальтернативная форматилка входит в тулчейн компилятора/интерпретатора.
Таков путь садо-мазо: автор хочет писать жаву в vim...
Сделали бы как в go, единый код стайл, шаг в сторону - ошибка компиляции
Ага, закомментировал строчку, образовался неиспользуемый импорт. Сначала удали импорт, потом пробуй запустить код, чтобы посмотреть, что будет без этой строки. Потом раскомментируй строку и верни обратно импорт. Воркфлоу моей мечты )))
И из зависимостей выкинет, елси это было единственное использование.
Можно использовать if false { ... } вместо комментирования, хотя есть свои плюсы и минусы.
Вы кажется не разобрались, как в IDE настроить авто импорт.
А зачем простите коммментировать код, чтобы понять как программа себя ведет без него? Это какой-то частный случай дебага?
Это следствие современной секты, когда софт скилы, аджайл, 6 часов созвонов в день пришли на замену хард скилам 😂
Вы кажется не разобрались, как в IDE настроить авто импорт.
Там же не надо разбираться, он же есть из коробки. Правда надо спозиционироаться на строке в которой класс без импорта и нажать Alt + Enter. А потом выбрать, какой конкретно класс надо импортировать.
А зачем простите коммментировать код, чтобы понять как программа себя ведет без него?
А есть ещё какой-то другой способ узнать как программа ведёт себя без этого кода?
Это какой-то частный случай дебага?
Ну да. Обычно при прогоне юнит тестов таким занимаешься. Но бывает что и в разработке, хоть и редко
Используем codestyle от intellij с форматированием на основе ОБЩЕПРИНЯТОГО google style. А в качестве плагина для проверки билда для CI - checkstyle. Codestyle с проектом в git.
Не понимаю, разговоров об отсутствии конвенции. Есть два варианта: олдскульный oracle java code style convention и google java code style convention.
Проблема реально высосана из пальца.
clang-format не рассматривался? Заявляет, что умеет в Java (в том числе)
Для С++ пользуем в конторе давно
Интересно. Почему то считал что уж в java то есть подобный единый инструмент. Хорошо что в python есть black - может не идеальный, но вроде как почти де-факто стандарт
У вас возникло желание вернуться в Java после Scala?
Почему нет достойных форматтеров кода для Java?