Каков правильный стиль для импорта списка в Java?

Question

Лучше ли перечислить каждый отдельный фрагмент пакета, который вам понадобится (см. # 1), или лучше просто импортировать все из пакета (см. # 2)?

1

import java.awt.image.ColorModel;
import java.awt.image.ComponentColorModel;
import java.awt.image.ColorConvertOp;

2

import java.awt.*;

Answer 1

Это НЕ просто вопрос стиля; импорт по требованию может привести к тому, что код перестает компилироваться при добавлении новых классов в существующие пакеты.

Основная идея (Подробнее см. http://javadude.com/articles/importondemandisevil.html.):

import java.awt.*;
import java.util.*;
...
List list;

работал в Java 1.1; начиная с Java 1.2 приведенный выше код больше не будет компилироваться.

Импорт по требованию ЗЛО , потому что ваша программа может остановить сборку, когда новые классы добавляются в существующие пакеты!

ВСЕГДА использовать явный импорт. Это не вопрос стиля; это вопрос безопасности.

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

(Импорт по требованию является примером действительно плохой функции языка программирования - никакая функция не должна нарушать код при добавлении новых типов в систему!)

Answer 2

Используйте импорт по отдельности.

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

Хотя среда IDE отлично справляется с задачей, помогая вам узнать, какие классы используются, легче понять, что вы имеете в виду:

java.util.List;

а не

java.awt.List; 

и т. Д.

Кроме того, рекомендуется группировать их по пакетам, начиная с основных библиотек, передаваемых сторонними разработчиками и заканчивая собственными библиотеками проекта:

 import java.util.List;
 import java.util.ArrayList;
 import java.util.Date;

 import javax.swing.JFrame;
 import javax.swing.JPanel;

 import javax.swing.event.TableModelListener;

 import org.apache.commons.httpclient.cookie.CookiePolicy;
 import org.apache.commons.httpclient.cookie.CookieSpec;

 import your.own.packagename.here.SomeClass;
 import your.own.packagename.here.OtherClass;

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

Answer 3

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

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

Итак, полный ответ:

• Использование оператора импорта не требует затрат времени выполнения
• Процесс компиляции может занять немного больше времени при импорте Заявление
• Процесс компиляции может занять еще больше времени при импорте подстановочного знака Заявление
• Для улучшения читаемости операторы импорта с использованием подстановочных знаков являются плохой практикой для все, кроме одноразовых занятий
• Затраты на компиляцию операторов импорта без подстановочных знаков незначительные, но они дают читабельность Преимущества, поэтому лучшая практика заключается в использовании их

- это плохая практика использовать операторы импорта wilcard, они делают код менее читабельным, просто не делайте этого. Единственное исключение из этого правила - статический импорт, например import static org.junit.Assert.*;. Нет, я не хочу импортировать каждый assertXXX по отдельности и не считаю, что это вредит читабельности кода.

Answer 4

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

Answer 5

Последний обычно считается "плохой формой". Благодаря поддержке инструментов нет оправдания тому, что они не перечислены по отдельности, и это устраняет любую двусмысленность.

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

edit: задним числом различие очевидно - статический импорт часто ссылается на статические методы, и вы не можете однозначно ссылаться на статический метод по имени (из-за перегрузки). Поэтому, если оно не может быть полностью однозначным, вы можете использовать подстановочный знак.

Answer 6

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

Answer 7

Опция 1, которую вы перечислили, предпочтительнее, но если есть больше классов, которые вы импортируете, скажем, из java.awt.image, тогда предпочтительнее всего один импорт java.awt.image. * Большинство IDE позволяют вам указать точное количество от количества импортируемых товаров. Например, в IDEA мы можем использовать File->Settings->Code Style->imports. На вкладке Общие есть поле Class count to use import with *, а значение по умолчанию - 5.

.

Answer 8

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

Answer 9

Если вы используете ide как visual studio, он, как правило, решает эту проблему для вас, поэтому вам даже не нужно думать об этом.

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

Answer 10

Здесь нет единственно правильного ответа.

Люди, которые принесли вам Eclipse, проголосовали за отдельный импорт, так как Source / Organize Imports преобразует * форму в конкретную форму.