Scala: Где я должен разместить операторы импорта?

Question

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

Обычно я стараюсь соблюдать эти правила (придуманные мной):

• Если я импортирую что-товнешний от другого пакета, я всегда помещаю его сверху сразу после «пакета».
• Если я использую что-то более одного раза в одном и том же файле, я также импортирую это вверху.
• В противном случае я размещаю свои импорта в верхней части соответствующего класса / признака / объекта.
• Я избегаю импортировать вещи в методах и блоках.
• Я стараюсь избегать импорта содержимого объектов экземпляра, если только у меня нет действительно веской причины для этого.
• Я бы не стал переименовывать и «прятать», если только не разрешал коллизии имен, но мне это еще никогда не было нужно.эти "правила" имеют для вас смысл?Я слишком ограничиваю себя?

Answer 1

Обычно имеет смысл ограничить область действия чего-либо (например, переменной или метода) до «наименьшего», насколько это возможно. Например, используйте внутренний def, а не один на уровне класса. Почему операторы импорта должны отличаться? Зачем загрязнять класс импортом, который используется только в одном блоке?

Мне нравится объявлять импорт как можно ближе к месту его использования!

Результатом этого является то, что общие утилиты, обе библиотеки, такие как scalaz и моя собственная, имеют тенденцию импортироваться один раз на верхнем уровне (потому что они используются во всем классе). Принимая во внимание, что такие вещи, как ввод-вывод, импортируются локально, только там, где они используются

Answer 2

Поместите импорт в начало файла.

Распределение их по всему файлу затрудняет чтение кода:

• Они передаютнет логического значения, они просто псевдоним;таким образом, они «загрязняют» код, который отражает логический аспект программы.
• Нельзя ожидать, где их найти (для этого существуют соглашения).
• В файлах с несколькими ссылкамидля сущностей с одинаковыми именами, но с другим пространством имен, трудно отследить, на что ссылается это имя в каждой области.

Я не вижу смысла размещать их рядом с ближайшей областью действия.На самом деле, с учетом этих соображений, никогда не следует использовать их вообще;вместо этого всегда следует использовать полное пространство имен для каждой ссылочной сущности.Имеет ли это смысл?ИМХО, нет.

Answer 3

рекомендации по импорту в Effective Scala говорят:

Поместить импорт в начало файла

Читатель может обратитьсяко всем импортам в одном месте.

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

При работе с большими файлами многие людиимеют тенденцию смотреть только на свой локальный фрагмент кода, поэтому они могут локально импортировать что-то, что конфликтует с другими частями пакета (например, в одном классе Promise импортируется из scala.concurrent, а в другом из akka.dispatch), иэто труднее обнаружить, когда импорт разбросан повсюду.

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

Редактировать: удалил ссылку на правило BlockImportChecker ScalaStyle , котороене связано.

Answer 4

Вы должны помнить, что Scala все еще является компилируемым языком, и все правила, применимые к Java как языку компиляции, применимы и к Scala. Компилятор должен знать, какой символ вы имеете в виду, когда произносите List или Function.

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

Answer 5

Нет.

Я избегаю импортировать вещи в методах и блоках.

Почему?

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

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

Для меня это выглядит так, как будто вы придерживаетесь некоего правила порядка: «импорт относится к началу», который может происходить из языка, который вы изучали ранее, где существует объективная необходимость их размещениянаверху.Без необходимости вы могли бы упорядочить их близко к первой зависимости, чтобы легко их удалить, если вы удалите зависимый код и упростите для читателя выяснить, почему импорт существует и откуда класс или признакимпортируется, например, коллекциями.mutable может быть такой импорт.