Scala：我应该在哪里放置导入语句？
Scala 几乎允许您在任何地方导入任何您想要的内容，这非常棒。但是，在类、方法或任何块中导入某些内容时，我应该考虑哪些注意事项？它与代码的性能、风格、可维护性等有何关系？
一般来说，我尝试遵守这些规则（由我自己制定）：
- 如果我从其他包导入外部内容，我总是将其放在“包”之后的顶部。
- 如果我在同一个文件中多次使用某些内容，我也会将其导入顶部。
- 否则，我将导入放在相关类/特征/对象的顶部。
- 我避免在方法和块中导入内容。
- 我尽量避免导入实例对象的内容，除非我有充分的理由这样做。
- 我会避免重命名和“隐藏”，除非解决名称冲突，但我从来没有需要这样做。
这些“规则”对你来说有意义吗？我是不是对自己限制太多了？
Scala allows to import almost whatever you want, wherever you want, and this is great. But are there any considerations I should take into account when importing something inside class, method or just any block? How does it relate to performance, style, maintainability of code, etc?
Generally I try to obey these rules (made up by myself):
- If I'm importing something external from other package I always place it at the top just after the "package".
- If I'm using something more than once in the same file, I also import it at the top.
- Otherwise I place my imports at the top of the relevant class/trait/object.
- I avoid to import things in methods and blocks.
- I try to avoid importing contents of instance objects, unless I have a really good reason to do so.
- I would avoid renaming and "hiding" unless to resolve name collisions, but I have never needed that yet.
Do those "rules" make sense to you? Am I restricting myself too much?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尽可能将某事物（例如变量或方法）的范围限制到“最小”通常是有意义的。例如，使用内部定义而不是类级别的定义。为什么导入语句应该有所不同？为什么要使用仅在单个块中使用的导入来污染类？
我喜欢在尽可能靠近它们使用的地方声明进口！
这样做的结果是，常见的实用程序，例如 scalaz 和我自己的库，往往会在顶层导入一次（因为它们在整个课程中使用）。而像 I/O 这样的东西只能在使用它的地方导入
It usually makes sense to restrict the scope of something (e.g. a variable or a method) to the "least" as it is possible. For example, use an inner def as opposed to one at the class level. Why should import statements be any different? Why pollute a class with imports which are only used in a single block?
I like to declare imports as close to where they are used as possible!
The upshot of this is that common utilities, both libraries like scalaz and my own, tend to get imported once at the top-level (because they are used throughout the class). Whereas stuff like I/O gets imported locally, only where it is used
将导入放在文件的顶部。
将它们分散在整个文件中会使代码更难阅读：
我认为将它们放在最近的瞄准镜旁边没有任何好处。事实上，考虑到这一点，人们根本不应该使用它们；相反，应该始终对每个引用的实体使用完整的命名空间。这有什么意义吗？恕我直言，不。
Put imports at the top of a file.
Having them scattered all over a file makes it harder to read the code:
I see no benefit in placing them next to their closest scope. Actually, with this reasoning in mind, one should never use them at all; instead, one should always use the full namespace for every referenced entity. Does that make any sense? IMHO, no.
您应该记住，Scala 仍然是编译语言，适用于 Java 作为编译语言的所有规则也适用于 Scala。当您说
List或Function时，编译器应该知道您所指的符号。您可以使用块内导入语句，但请谨慎使用。过度使用可能会导致其他人对源文件的理解不一致。如果单个类边界将根据上下文使用两个不同的
List定义，则会很不方便。You should remember that Scala is still compiled language, and all the rules applicable to Java as a compile language are applicable to a Scala also. Compiler should know what symbol you mean when you say
ListorFunction.You could use in-block import statements but use them carefully. Overusing may lead to inconsistent understanding of the source files by other people. It would be inconvenient if single class boundary will use two different definition of
Listdependent on context.effective Scala 中的导入指南说：
在我使用过的一些代码库中，倾向于在同一文件的多个位置多次导入相同的内容，因为开发人员没有检查这一点。如果 IDE 在检测到块级导入的多个实例时能够自动提升块级导入，那就太好了，但据我所知，我使用的 (IntelliJ) 并没有这样做。
在处理大文件时，许多人倾向于只查看本地代码段，因此他们可能会在本地导入与包的其他部分冲突的内容（例如，在一个类中
Promise是从 < code>scala.concurrent，以及来自akka.dispatch的另一个），当你的导入遍布各处时，很难检测到这一点。这可能与您的特定代码库相关，也可能无关，但我个人倾向于对我维护的代码（熵等）持悲观态度，因此尝试从一开始就制定规则，以确保长期的可维护性。
编辑：删除了对 ScalaStyle 的 BlockImportChecker 规则，这不相关。
The import guidelines in Effective Scala say:
In some code bases I've worked with, there was a tendency to import the same thing multiple times in several places in the same file, because the developer didn't check for this. It would be nice if IDEs could automatically promote block-level imports if they detect multiple instances of them, but AFAIK the one I use (IntelliJ) doesn't do this.
When working on large files, many people tend to only look at their local piece of code, so they may locally import something that conflicts with other parts of the package (e.g. in one class
Promiseis imported fromscala.concurrent, and in another fromakka.dispatch), and it's harder to detect this when you have imports sprinkled all over the place.This may or may not be relevant to your particular code base, but I personally tend to be pessimistic about the code I maintain (entropy and all that) and thus try to institute rules from the start that would ensure maintainability in the long run.
Edit: removed a reference to ScalaStyle's BlockImportChecker rule, which is not related.
不。
为什么？
如果你感觉到差异，那么一定是客观差异，因为感受是客观事件，并非无中生有。
它们可以被测量——用我们现有的仪器并不容易和精确——而且也许你无法与其他客观事实联系起来来解释这些感觉。
在我看来，你似乎碰巧遵守了一种顺序规则，“导入属于顶部”，这可能源于你之前学过的一种语言，客观上有必要将它们放在顶部。如果没有必要，您可以将它们排序为靠近第一个依赖项，以便轻松删除它，如果您删除依赖项代码并使读者更容易弄清楚导入的原因以及类或特征来自何处被导入，例如 collections.mutable 可能就是这样的导入。
No.
Why?
If you feel a difference, there has to be an objective difference, because feelings are objective events and don't origin from nothing.
They can be measured - not easily and precisely with our current instruments - and maybe you aren't able to draw connections to other objective facts, which explain these feelings.
To me it looks as if you happen to stick to a kind of order rule, "imports belong to the top", which might origin from a language you learned before, where there is an objective necessity to place them on top. Without the necessity, you might order them close to the first dependency, to delete it easily, if you delete the depending code and make it easy for the reader, to figure out, why the import is there, and from where a class or trait is imported, for example collections.mutable might be such an import.