为什么-compile（export_all）不好的做法？

所有的erlang书似乎都说export_all是不好的做法，但是不要说明理由。最终，大多数模块花费大部分时间用于编译（export_all），因为不断更新模块列表以删除辅助函数是一件麻烦事。这是不好的做法，因为我应该关心我向其他开发者公开的功能吗？或者这是不好的做法，因为模块所具有的功能数量会带来某种性能成本，这可能与热代码加载有关。如果在填充具有很多功能的模块时性能受到影响，它有多糟糕？为什么-compile（export_all）不好的做法？

来源

2011-10-22 Jazz Man

因为反向工程更容易，并且不必要地生成比需要更大的可执行文件。没有人需要你的函数名称在可执行权？ – fazo

以下几个原因：

净度：它更容易看到哪些功能旨在模块外部使用。

当您在Erlang shell中完成选项卡时，只会列出导出的功能列表，而不会包含其他功能。重构模块时，您会知道无需外部用户就可以安全地重命名哪些函数，具体取决于它们。
代码异味：你会得到未使用函数的警告。

因此，你会避免死代码。
优化：编译器可能能够进行更积极的优化，因为知道并非所有函数都必须导出。

来源

2011-10-23 17:28:35

您是否有资源来备份优化声明？ – jocull

不幸的是，但我想像它能够内联仅在一个地方使用的函数，例如，如果它知道他们永远不会从模块外部调用。 –

此外，它使透析器更难使用。 @jocull在Joe Armstrong的书中，Programming Erlang，2nd ed。，pg。 164，他指出，当你输出较少的函数时，“编译器可以产生更好的代码”。 – JDong

尽管我不确定使用-compile(export_all).是否有任何实际的性能影响，但我怀疑它们是否足够重要。

但是，显式声明导出列表有好处。通过这样做，每个人都可以通过查看.erl文件的第一页来找出模块的界面。此外，与我们倾向于写下的许多其他内容一样，显式声明模块接口有助于保持其清晰度。

随着中说，当我开始一个新的Erlang模块上工作，我总是键入-module(...). -compile(export_all).界面变得成熟后，我够添加一个显式-export([...])同时保持的export_all编译选项。

来源

2011-10-23 00:26:40 alavrik

没有使用'-compile（export_all）.'的性能影响。编译器处理所有调用都是一样的，导出过程与显式导出相同。 – rvirding

定义了哪些函数是外部的，因此哪些函数是内部函数的列表对于将来处理您的代码的人非常有用。我最近重构了一些旧代码，并且在大多数模块中使用export_all一直是一个烦恼的持续源。

来源

2011-10-23 09:51:59 barrym

为什么-compile（export_all）不好的做法？

回答

相关问题