Любая причина для очистки неиспользуемого импорта в Java, кроме уменьшения беспорядка?

Question

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

(Я спрашиваю, потому что Eclipse выдает предупреждение о неиспользованном импорте, что немного раздражает, когда я разрабатываю код, потому что я не хочу удалять импорт, пока я не уверен, что закончил разработку класса. )

Answer 1

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

Но могут быть конфликты имен, в редких случаях, например, при импорте интерфейса списка.

В Eclipse вы всегда можете использовать ярлык (зависит от ОС - Win: Ctrl + SHIFT + O и Mac: COMMAND + SHIFT + O) для организации импорта. Затем Eclipse очищает раздел импорта, удаляет весь устаревший импорт и т. Д. Если вам снова понадобится импортированная вещь, eclipse добавит их автоматически, когда вы заполняете оператор с помощью Ctrl + SPACE. Поэтому нет необходимости хранить неиспользуемый код в вашем классе.

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

Answer 2

Можно предположить, что если вы удалите класс, на который ссылается импорт, из пути к классам, вы не получите глупую ошибку компилятора, которая не имеет смысла. И вы не получите ложных срабатываний при выполнении поиска «где используется».

Другое (но это было бы очень специфично по своей природе) было бы, если бы неиспользуемый импорт имел конфликт имен с другим импортом, что приводило к ненужному использованию полных имен.

Приложение: сегодня на сервере сборки начался сбой компиляции (даже не тестовый запуск) с ошибкой нехватки памяти. Он работал нормально всегда, и у изменений не было никаких изменений в процессе сборки или существенных дополнений, которые могли бы объяснить это. После попытки увеличить параметры памяти (это 64-битная JVM на 64-битной CentOS!) До уровня, намного превышающего возможности компиляции клиентов, я проверил проверки по одному.

Был неправильный импорт, который разработчик использовал и отказался (они использовали класс, автоматически импортировали его, а затем поняли, что это ошибка). Этот неиспользованный импорт включил целый отдельный уровень приложения, который, хотя IDE не настроен для их разделения, представляет собой процесс сборки. Этот единственный импорт затянул так много классов, что компилятор пытался скомпилировать, не имея соответствующих зависимых библиотек в пути к классам, что вызвало столько проблем, что вызвало ошибку нехватки памяти. Чтобы решить эту проблему, вызванную неиспользованным импортом, понадобился час.

Answer 3

С точки зрения пуристов, любая зависимость является «ограничением» для продукта и, таким образом, может впоследствии вызвать проблемы с техническим обслуживанием.

Например, давайте предположим, что ваша программа использует класс com.X.Y.Z.ObjectPool, и что позже вы решите не использовать его, но никогда не удаляете импорт. Если кто-то другой сейчас хочет создать экземпляр org.W.V.Y.ObjectPool и просто обратиться к ObjectPool, он не получит никакого предупреждения об этом, пока где-нибудь не возникнет проблема с приведением или вызовом.

Это, кстати, нереальный сценарий. Каждый раз, когда у вас Eclipse спрашивает, какую конкретную версию X вы хотите импортировать, и вы выбираете одну из множества пакетов, это сценарий, при котором, если у вас был импорт, вы могли ошибиться, не зная об этом.

В любом случае, вы можете попросить Eclipse очистить их для вас

Answer 4

К вашему сведению, это застало меня врасплох, так как я не думал, что организация импорта фактически удаляла неиспользованный импорт, я думал, что он просто отсортировал их.

Автоматическое удаление импорта во время операции сохранения вызвало у меня некоторое горе, когда, например, во время разработки или тестирования у вас возникла проблема и закомментировали некоторый код, при его сохранении импорт, используемый закомментированным разделом кода, был удален. Иногда это не проблема, поскольку вы можете отменить ( Ctrl + Z ) изменения, но в других случаях это не так просто, как вы могли внести другие изменения. У меня также была проблема, когда, когда я раскомментировал код (я ранее закомментировал, а затем сохранил, тем самым удалив импорт для этого кода), он автоматически попытался угадать импорт, который был необходим, и выбрал неправильные (например, я думаю, что использовался класс StringUtils, и он выбрал другой класс с тем же именем из неверной библиотеки).

Я предпочитаю организовывать импорт вручную, а не сохранять его.

Answer 5

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

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

Подумайте о следующем сценарии:

import company.billing.*;
import company.humanrerources.*;

// other imports 


class SomeClass {
      // hundreds or thousands of lines here... 
    public void veryImportantMethod() {
      Customer customer;
      Employee comployee;
      Department dept. 
      // do something with them
     }
 }

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

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

Если это для личного проекта или чего-то небольшого, это действительно не имеет значения, но для чего-то большего, что должно использоваться другими разработчиками (и поддерживаться в течение многих лет), это ДОЛЖНО ИМЕТЬ.

Нет абсолютно никакой разницы в производительности.

Answer 6

Внимание? Попросите Eclipse автоматически очистить их для вас. Это то, что делает IntelliJ. Если он достаточно умен, чтобы предупредить вас, он должен быть достаточно умен, чтобы очистить их. Я бы порекомендовал поискать настройку Eclipse, чтобы она перестала быть такой придиркой и что-то сделала.

Answer 7

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

Answer 8

Для затмения я использую это: окно -> настройки -> java -> редактор -> сохранить действие -> установить флажок для организации импорта (там также есть много других полезных вещей, таких как форматирование, окончательное заполнение полей и скоро..). Поэтому, когда я сохраняю свой файл, Eclipse удаляет unessacry для меня. По моему мнению, если вам что-то не нужно, то удалите его (или пусть оно будет удалено затмением).

Answer 9

Нет никакого влияния на производительность, хотя для удобства чтения вы можете сделать его чистым. Удаление неиспользованного импорта довольно просто как в Eclipse, так и в IntelliJ IDEA.

Затмение

Windows / Linux - Ctrl + Shift + O

Mac - Cmd + Shift + O

IntelliJ IDEA или Android Studio

Windows / Linux - Ctrl + Alt + O

Mac - Cmd + Alt + O

Answer 10

Для меня один неиспользуемый класс импорта в классе контроллера создал проблему компиляции в сборке Jenkins после того, как я удалил импортированный класс во время очистки кода и зафиксировал удаление в git без тестирования сборки в локальной среде.