Scala：我应该在哪里放置import语句？

Question

Scala允许随意导入任何你想要的任何内容，这很棒。但是，在类，方法或任何块中导入内容时，我是否应该考虑任何因素？它与性能，样式，代码的可维护性等有何关系？

一般来说，我会尝试遵守这些规则（由我自己制定）：

• 如果我从其他软件包中导入外部内容，我总是将其放在“软件包”之后的顶部。
• 如果我在同一个文件中多次使用某些内容，我也会将其导入顶部。
• 否则我将导入放在相关类/特征/对象的顶部。
• 我避免在方法和块中导入内容。
• 我尽量避免导入实例对象的内容，除非我有充分的理由这样做。
• 除非解决名称冲突，否则我会避免重命名和“隐藏”，但我从未需要它。

这些“规则”对你有意义吗？我是在限制自己吗？

Answer 1

将内容（例如变量或方法）的范围限制为“最小”通常是有意义的。例如，使用内部def而不是类级别的内部def。为什么导入语句应该有所不同？为什么要污染具有仅在单个块中使用的导入的类？

我喜欢将导入声明为尽可能接近使用位置！

这样做的结果是，常见的实用程序，如 scalaz 和我自己的库，往往会在顶层导入一次（因为它们在整个类中使用）。而像I / O这样的东西会在本地导入，只有在使用它的地方

Answer 2

您应该记住，Scala仍然是编译语言，并且适用于Java作为编译语言的所有规则也适用于Scala。当您说List或Function时，编译器应该知道您的意思。

您可以使用块内导入语句，但要小心使用它们。过度使用可能会导致其他人对源文件的理解不一致。如果单个类边界将使用依赖于上下文的两个不同的List定义，那将是不方便的。

Answer 3

有效Scala中的import guidelines说：

  

将导入放在文件的顶部

     

读者可以在一个地方引用所有进口货物。

在我使用过的一些代码库中，有一种趋势是在同一个文件中的多个位置多次导入同一个东西，因为开发人员没有检查这个。如果IDE在检测到它们的多个实例时可以自动提升块级导入，那将是很好的，但是我使用的AFAIK（IntelliJ）不会这样做。

在处理大型文件时，许多人往往只查看他们的本地代码，因此他们可能会在本地导入与包的其他部分冲突的内容（例如，从Promise导入的一个类scala.concurrent {1}}，以及来自akka.dispatch）的另一个，当您在整个地方都有进口商品时，很难发现这一点。

这可能与您的特定代码库相关，也可能不相关，但我个人对我维护的代码（熵和所有这些）持悲观态度，从而尝试从一开始就制定规则，以确保长期的可维护性运行

修改：删除了与ScalaStyle BlockImportChecker rule无关的引用。

Answer 4

将导入放在文件的顶部。

将它们分散在整个文件中会使得阅读代码变得更加困难：

• 它们没有任何逻辑意义，它们只是一个别名;因此，他们污染了＃34;反映程序逻辑方面的代码。
• 人们不能指望在哪里找到它们（这就是惯例的用途）。
• 在对具有相同名称但名称空间不同的实体的多个引用的文件中，很难跟踪该名称在每个范围内引用的内容。

我认为将它们放在最近的范围旁边没有任何好处。实际上，考虑到这种推理，人们根本不应该使用它们;相反，应该始终为每个被引用的实体使用完整的命名空间。这有任何意义吗？恕我直言，没有。

Answer 5

没有。

  

我避免在方法和块中导入东西。

为什么？

如果你感觉有所不同，就必须有客观的差异，因为感受是客观事件而不是从无到有。

它们可以通过我们现有的工具进行测量 - 不容易和精确 - 也许你无法与其他客观事实联系起来，这可以解释这些感受。

对我来说，看起来好像你碰巧遵守一种秩序规则，“进口属于顶级”，这可能源于你之前学到的一种语言，在那里客观上有必要把它们放在首位。没有必要，您可以将它们命令接近第一个依赖项，以便轻松删除它，如果您删除依赖代码并使读者容易理解，为什么导入存在，以及从哪个类或特征是导入的，例如collections.mutable可能是这样的导入。