Valhalla в Java

ENCODING
METHOD

О да, очень понятно что это такое и откуда его принесло.
Вот импорт таких констант я больше всего не люблю. А если константа строковая то вообще элементарно вместо одного METHOD импортировать совсем другой METHOD и даже не заметить это.

Смотри. Вот я специально провел эксперимент. Поставил в коде UTF_8, нажал «Import static constant...» и получил выпадающий список с 11 элементами (из пакетов java.io.charset, org.apache.commons..., org.apache.http, com.google.common.base, ...).

Вот импорт таких констант я больше всего не люблю

А я больше всего не люблю StandardCharsets.UTF_8. Не то, чтобы трясёт, но пальцы сами тянутся к Alt+Enter-у.

А если константа строковая то вообще элементарно вместо одного METHOD импортировать совсем другой METHOD и даже не заметить это.

Нет, это не элементарно. Это надо выбрать другой METHOD. Не заметить это невозможно, там меню появляется, где ты сам всё выбираешь.

Смотри. Вот я специально провел эксперимент. Поставил в коде UTF_8, нажал «Import static constant…» и получил выпадающий список с 11 элементами (из пакетов java.io.charset, org.apache.commons…, org.apache.http, com.google.common.base, …).

И какие выводы читатель должен был сделать из этого эксперимента?

Нет, это не элементарно. Это надо выбрать другой METHOD. Не заметить это невозможно, там меню появляется, где ты сам всё выбираешь.

Я о том, что при выборе из списка можно ошибиться.

И какие выводы читатель должен был сделать из этого эксперимента?

Я ему предлагаю следующие выводы:
1. Что не нужно использовать статические импорты, чтобы не было потом пляски с поиском где же живет нужная константа.
2. Ну и статический импорт не сработает если тебе нужно две константы с одинаковым именем в файле.
3. Импортировать константы вроде INSTANCE еще большее веселье.

Я о том, что при выборе из списка можно ошибиться.

Не надо ошибаться. Надо быть внимательным.

1. Что не нужно использовать статические импорты, чтобы не было потом пляски с поиском где же живет нужная константа.

Да нет никакой пляски. Всё очевидно.

2. Ну и статический импорт не сработает если тебе нужно две константы с одинаковым именем в файле.

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

3. Импортировать константы вроде INSTANCE еще большее веселье.

Да, такие константы статически импортировать не надо. Напишу в третий раз. Статически импортировать надо те идентификаторы, по названию которых понятно, что они делают и добавление имени класса не добавляет существенной информации к контексту. По названию UTF_8 понятно, что это кодировка. От того, что ты добавишь префикс StandardCharsets., понятней не станет. Зато ты перегрузил мозги читателя ненужной информацией и он теперь пропустит баг в следующей строчке. По названию INSTANCE вроде и понятно, что это какой-то синглтон, но SuperDuper.INSTANCE добавляет существенную информацию. Поэтому тут можно и не импортировать статически эту константу.

Я так понимаю, что твой подход нацелен на взаимодействие с отходами жизнедеятельности обезьян, которые программируют на клауде вайбе с закрытыми глазами, пушат код сразу же, как только он скомпилировался и при просмотре diff-а pull-request-а ты хочешь сразу увидеть, что они импортировали какую-то дичь? Хотя в diff-е импорты будут вообще идти в самом верху и это можно и так понять… Я же не призываю использовать wildcard импорты. Это бяка, да.

Не надо ошибаться. Надо быть внимательным.

Действительно, нафиг нам вообще эта статическая типизация.

Да нет никакой пляски. Всё очевидно.

Это голословное и ничем не подтвержденное утверждение. Никак не очевидно, из какого класса эта константа.

Но оба этих случая - скорей редкость, нежели правило.

Встретить конфликт Foo.bar намного меньше чем Foo и bar по отдельности.

Статически импортировать надо те идентификаторы, по названию которых понятно, что они делают и добавление имени класса не добавляет существенной информации к контексту.

Тут проблема еще в том, что ты можешь или разрешить стат. импорты
или нет. Очень сложно договориться о правиле «импортируем только в случаях А, Б и В».

По названию UTF_8 понятно, что это кодировка.

Не факт. Например, я легко могу представить StringSerializers.UTF_8 — которая синглтон сериализатора. Часто вижу такой шаблон.

Я так понимаю, что твой подход нацелен на взаимодействие с отходами жизнедеятельности обезьян, которые программируют на клауде вайбе с закрытыми глазами

Не угадал.
Но, главное, ты дрогнул — пошли аргументы в духе «а у тебя трусы рваные».

но и методы присутствуют

там этих методов навалом, которые так и просятся на статический импорт, навскидку:

• весь AssertJ (https://joel-costigliola.github.io/assertj/, кто не использует fluent assertions - стыдно быть таким)
• java.util.function.Predicate#not - постоянно в filter используется, писать Predicate.not(Class::isXXX) - как-то тупо
• почти все из java.util.stream.Collectors
• почти все из java.util.Comparator и производные типа java.util.Map.Entry#comparingByKey

Тут проблема еще в том, что ты можешь или разрешить стат. импорты или нет. Очень сложно договориться о правиле «импортируем только в случаях А, Б и В».

Прямо какая-то параллельная вселенная…

https://checkstyle.sourceforge.io/checks/imports/avoidstaticimport.html:

<module name="Checker">
  <module name="TreeWalker">
    <module name="AvoidStaticImport">
      <property name="excludes" value="java.lang.System.out,java.lang.Math.*"/>
    </module>
  </module>
</module>

один раз настраивается и все.

Согласен со всеми примерами.

Если бы еще легко было внедрить CheckStyle в какой-то зрелый проект. В большинстве случаев это почти нереально.
Хотя, один пример я видел.

А что там сложного? Там же всё на 100% настраивается. Начинаешь с нуля и шаг за шагом внедряешь правила. Вопрос желания руководства тратить на это усилия разработчиков.

почти нереально

основываясь на:

Смотри. Вот я специально провел эксперимент. Поставил в коде UTF_8, нажал «Import static constant…» и получил выпадающий список с 11 элементами (из пакетов java.io.charset, org.apache.commons…, org.apache.http, com.google.common.base, …).

становится очевидно, что проект - это не проект, а помойка: и морально устаревший commons-lang, и встарая guava, и checkstyle нет, наверняка еще никому не приходило в голову за зависимостями следить. А мы тут обсуждаем как код писать и что законодательно запрещать, ну-ну…

становится очевидно, что проект - это не проект, а помойка

Не угадал. Это библиотека и зоопарк апачей там необходим.

Если у тебя проект не соло-поделка из 10 классов то возникает ворох вопросов: от человеческих ресурсов (которых всегда не хватает) и до интеграции с различными процессами и программами. А в большой конторе, с отделами и прочей бюрократией вообще принять какой-то стандарт почти нереально — со всех углов кричат «а почему я должен форматировать код так, как хочешь именно ты?».
Гугл вот молодец, у них очень давно принят стиль для каждого языка. Больше я примеров таких не знаю и в реальной жизни не видел. В СПО разве, там да, часто есть.

Начинаешь с нуля и шаг за шагом внедряешь правила.

Верно. Только на это нужно 100500 человекочасов. Если у тебя 100500 файлов в проекте то никому не понравится, что ты одним PR'ом переформатируешь пол проекта. Ну а мелкими шажками это растянется на длительное время. Во время которого, еще и паралельно код пишут и вылазят назойливые конфликты через твое форматирование.

Это у тебя на словах выходит — кинул XML-файлик и все работает. В реальной жизни все немного сложней.

Не угадал. Это библиотека и зоопарк апачей там необходим.

наверняка эта библиотека столь важна, что пришлось все говно из интернета собрать, и еще мы жалуемся что код из более других источников не копируется, но виноват здесь import static, угу…

А в большой конторе, с отделами и прочей бюрократией вообще принять какой-то стандарт почти нереально — со всех углов кричат «а почему я должен форматировать код так, как хочешь именно ты?»

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

наверняка эта библиотека столь важна, что пришлось все говно из интернета собрать

Какое говно? Ты на Яве вообще писал? Это некогда одни из самых популярных HTTP-клиентов. Может и даже до сих пор популярнейший.

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

Проблема в том, что ты рассуждаешь о проектах/компаниях уровня стартапа с тремя калеками. Пример с Гуглом я тебе уже приводил, где есть огромнейшая кодовая база, есть принятый стандарт написания кода. Там твой прораб (тимлид) может выбирать только цвет смузи в стаканах команды, а не выпилить ли ему Апачи из проекта и заменить очередной хипстерской чепухой со случайного профиля на Github.