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

импорт Использования индивидуально.

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

, В то время как 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;

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

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

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

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

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

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

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

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

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

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

. Вариант 1, который вы указали, предпочтительнее, но если есть больше классов, вы импортируете, скажем, Java.awt.image, то его предпочтительнее просто иметь один импорт Java.awt.Image. * Большинство IDE позволяют указать точное количество количества его импорта. Для, например, в идее, мы можем использовать Файл-> Настройки-> Стиль кода-> Импорт На вкладке «Общие» есть поле Количество класса для использования импорта с помощью * и значение по умолчанию 5.

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

Я попытался использовать onRetainNonStartInstance (возвращая WebView ), затем вернуть его с помощью getLastNonStartInstance во время onCreate и переназначить его.

Кажется, пока не работает. Я не могу не думать, что я очень близка! Пока я просто получаю пустой/белый фон WebView . Размещение здесь в надежде, что кто-то может помочь протолкнуть это мимо финиша.

Возможно, мне не следует передавать WebView . Возможно, объект из WebView ?

Другой метод, который я пытался - не мой любимый - это задать это в действии:

 android:configChanges="keyboardHidden|orientation"

... и тогда ничего здесь не делать:

@Override
public void onConfigurationChanged(Configuration newConfig) {
  super.onConfigurationChanged(newConfig);
  // We do nothing here. We're only handling this to keep orientation
  // or keyboard hiding from causing the WebView activity to restart.
}

ЭТО работает, но это может не считаться наилучшей практикой .

Между тем, у меня также есть один ImageView , который я хочу автоматически обновлять в зависимости от поворота. Это оказывается очень легко. В папке res у меня есть drawable-land и drawable-port для хранения альбомных/портретных вариаций, затем я использую R.drawable.myimagename для источника ImageView и Android «делает правильно» - да!

... за исключением тех случаев, когда вы смотрите изменения конфигурации, то это не.: (

Так что я расходится. Используйте onRetainNonStartInstance и ротация ImageView работает, но сохранение WebView не... или используйте onStartChanged , а WebView остается стабильным, но ImageView не обновляется.

Последнее замечание: в моем случае принуждение к ориентации не является приемлемым компромиссом. Мы действительно хотим изящно поддержать ротацию. Как и приложение Android Browser!;)

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

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

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

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

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

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