为什么 -compile(export_all) 是不好的做法？
所有的erlang书籍似乎都说export_all是不好的做法，但没有给出理由。最后，大多数模块将大部分时间都花在了compile(export_all)上，因为不断更新模块列表以删除辅助函数是很麻烦的。这是不好的做法吗，因为我应该关心我向其他开发人员公开的功能？或者这是不好的做法，因为模块具有的功能数量会带来某种性能成本，可能是因为热代码加载之类的事情。如果在模块中填充大量函数会对性能造成影响，那么情况有多严重呢？
All the erlang books seem to say export_all is bad practice but don't give a reason. In the end most modules spend a majority of their time with compile(export_all) because constantly updating the list of modules to remove the helper functions is a hassle. Is it bad practice because I'm supposed to care about the functions I expose to other developers? Or is it bad practice because there's some kind of performance cost in the number of functions a module has, because of maybe things like hot code loading. If there is a performance hit to stuffing a module with a lot of functions, how bad is it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
出于以下几个原因：
清晰：更容易看出哪些函数打算在模块外部使用。
当您在 Erlang shell 中按 Tab 键补全时，您会得到一个仅包含导出函数的列表，而没有其他函数。当您重构模块时，您知道可以安全地重命名哪些函数，而无需外部用户依赖它们。
代码味道：您会收到未使用函数的警告。
因此您将避免死代码。
优化：编译器可能能够进行更积极的优化，因为知道并非所有函数都必须导出。
For several reasons:
Clarity: it's easier to see which functions are intended to be used outside the module.
When you tab complete in the Erlang shell you get a list of only the exported functions and no others. When you refactor the module, you know which functions you can safely rename without external users depending on them.
Code smell: you get warnings for unused functions.
Therefore you'll avoid dead code.
Optimization: the compiler might be able to make more aggressive optimizations knowing that not all functions have to be exported.
虽然我不确定使用
-compile(export_all).是否会对实际性能产生任何影响，但我怀疑它们是否足够重要，值得关注。然而，明确公布出口清单是有好处的。这样大家通过查看
.erl文件的第一页就可以弄清楚模块的接口了。此外，与我们倾向于写下的许多其他内容一样，模块接口的显式声明有助于保持其清晰度。话虽如此，当我开始开发新的 Erlang 模块时，我总是输入
-module(...)。 -compile(export_all)。接口变得足够成熟后，我添加显式的-export([...])同时保留export_all 编译选项。While I don't know for sure if there are any practical performance implications of using
-compile(export_all)., I doubt they are significant enough to care.However, there a benefit of declaring the list of exports explicitly. By doing this, everyone can figure out the interface of the module by looking at the first page of the
.erlfile. Also, as with many other things that we tend to write down, explicit declaration of the module interface helps to maintain its clarity.With that said, when I start working on a new Erlang module I always type
-module(...). -compile(export_all).After the interface becomes mature enough I add an explicit-export([...])while keeping theexport_allcompile option.定义哪些函数是外部函数以及哪些函数是内部函数的列表，对于将来处理您的代码的任何人都非常有用。我最近一直在重构一些旧代码，并且在大多数模块中使用 export_all 一直是一个烦恼的根源。
Having a defined list of which functions are external, and therefore which ones are internal, is extremely useful for anyone who will work on your code in the future. I've recently been refactoring some old code, and the use of export_all in most of the modules has been a continual source of annoyance.