В последнее время я стал использовать статические импорты всего, чего только можно почти везде. Исключение, если по имени функции непонятно, что она делает, а вместе с классом понятно. Например
String[] strings = ...;
List<String> list1 = asList(strings); // Arrays.asList
List<Integer> list2 = List.of(1, 2); // тут просто of это совсем уж непонятно, List.of читается понятней
С другой стороны есть статьи, в которых рекомендуют избегать статических импортов, мол непонятно, то ли это локальный метод, то ли нет. На мой взгляд это спорный аргумент, достаточно избегать статического импорта всех членов (import static Bla.*) и всё прекрасно понятно даже в блокноте, про IDE не говорю.
А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
Здравствуйте, vsb, Вы писали:
vsb> А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
С тобой согласен. И там к статье три комментария — с ними тоже согласен.
Здравствуйте, vsb, Вы писали:
vsb>А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
Больше не использую статический импорт вообще, хотя раньше считал его очень удобным и злоупотреблял им везде:
* Нет чётких критериев что считать подходящим под статический импорт. Аргумент в пользу asList или даже assertEquals базируется исключительно на привычке: например, для меня раньше приемлемым было писать что-то типа private static final Pattern newLine = compile("\\r?\\n"); ввиду того, что я привык к "compile" исключительно как к методу класса Pattern, хотя compile, к примеру, может быть чем-угодно, особенно если это какие-нибудь частные методы.
* При беглом просмотре кода мне кажется, что без статических импортов читать код легче, так как не нужно вспоминать, к какому из классов мог бы принадлежать тот или другой метод, поле, константа и т.д. Аргументы в пользу IDE не считаю сильными, потому что код читают, например, и при код-ревю или в консольном git diff (в изменения не всегда попадают импорты), и в статьях или на форумах (где импорты могут вообще опускать) и т.д. и т.п.
* Некоторые из потенциально подходящих имён кажутся настолько привлекательными, что декларируются несколькими классами, и при использовании таких имён приходится вибирать класс, больше подходящий на "почётное" место статического импорта. Если не ошибаюсь, Mockito и Hamcrest, используют одинаковые короткие имена, хоть и часто используются вместе.
Здравствуйте, vsb, Вы писали:
vsb>А как вы делаете?
использую, но каждый раз думаю, как лучше в каждом конкретном случае.
касательно .*: в некоторых специфических классах каких-нибудь маппингов удобно импортировать все константы названий полей, stream.Collectors тоже люблю все импортировать, т.к. в норме они по именам с локальными методами не пересекаются.
Здравствуйте, vsb, Вы писали:
vsb>А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
У нас в code style прописано, что статических импортов по возможности нужно избегать.
Я поначалу не обращал большого внимания на это правило, списывая на то, что код становится чуть короче и читабельнее (code style у нас позволяют некоторые вольности в разумных пределах, если это улучшает читабельность кода).
Поменял отношение пару месяцев назад, когда в мой код по ошибке воткнулся объект из какого-то другого пакета, но с тем же именем. Точно уже не помню, что именно там было, толи эксепшн, толи строка символов. Но в результате получалось, что я ожидал не тот объект и если б на код-ревью не заметили, то получился бы баг.
После этого я согласился, что статические импорты штука опасная. Сейчас я их частично применяю, но если только в результате там остается достаточно информации чтоб убедиться, что этот тот объект, что надо. Т.е., к примеру, не просто HttpException, а какой-нибудь Spring.HttpException. В этом случае туда не попадет случайно apache.common.HttpException (пример надуманный, просто чтоб объяснить мысль).
Здравствуйте, Artem Korneev, Вы писали:
AK>Поменял отношение пару месяцев назад, когда в мой код по ошибке воткнулся объект из какого-то другого пакета, но с тем же именем. Точно уже не помню, что именно там было, толи эксепшн, толи строка символов. Но в результате получалось, что я ожидал не тот объект и если б на код-ревью не заметили, то получился бы баг. AK>После этого я согласился, что статические импорты штука опасная. Сейчас я их частично применяю, но если только в результате там остается достаточно информации чтоб убедиться, что этот тот объект, что надо. Т.е., к примеру, не просто HttpException, а какой-нибудь Spring.HttpException. В этом случае туда не попадет случайно apache.common.HttpException (пример надуманный, просто чтоб объяснить мысль).
С другой стороны какой нибудь методы org/junit/Assert грех не импортировать.
Здравствуйте, vsb, Вы писали:
vsb>А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
Лично я только StringUtils и guava статически импортирую. Согласен с тем, что всё подряд не нужно. Но и полностью отказываться — тоже не вариант.
vsb>А как вы делаете? Какие ещё могут быть аргументы в какую-либо сторону?
Если имя метода полноценно само по себе и имя класса не делает ничего понятнее, предпочту статический импорт. Например assertEquals() vs. Assert.assertEquals() — второй вариант ничего не добавляет кроме лишнего текста. С другой стороны если имя метода само по себе неполноценно и прибито гвоздями к имени класса — как Arrays.asList(), конечно стоит имя класса оставлять.
