[erlang-questions] 回复: Is export always better than complie(export_all)?

Richard A. O'Keefe ok@REDACTED
Thu Jun 20 08:31:45 CEST 2013

> 在 2013年6月20日星期四,下午1:57,饕餮 写道:
>> I'm working in a program as 10,000 line code.
>> Most of the time the function are changing.

So what's new?  It was ever thus.

>> And all the team member should read all of the code.
>> And I usually use compile expert_all because I feel it make the work easier to handle

For whom?

The more you export, the harder it is for someone to find the
one function they need.
The more you export, the more others will depend on exactly what
the current version does, so the less you will be able to change.

You should at all times have a *design* that says what
services a module is *intended* to provide to the rest of
the system.

You MUST export the minimal set of functions that are necessary
for *outside* code to use those services.
You MAY export some 'convenience' functions defined in terms
of the core functions.
You SHOULD NOT export anything else.

How often I've read "look, here are these neat undocumented features
of System X version N", followed a few years later by "Those wicked
builders of System X broke all my programs in version N+1 when the
undocumented functions changed/went away."

>> But one of my teammate said that I must never use export_all.

He's wrong too.  When debugging, it is useful to be able to refer
to anything in a module.  But you can do that with compiler command
line switches/option lists.

>> It's that necessary to use export() instead of compile(export_all)?
>> And what's the reason to use export?

To make it clear to yourself, to the system, and to other people
which functions are part of the interface and may be safely called
outside, and which other functions (by omission) are *not*, and may
be changed without anyone else having any right to complain.

If you export everything, you are promising everyone else who uses
your module that you'll try very hard to keep *all* of those
functions' interfaces unchanged for a rather long time -- as the
project counts time.

More information about the erlang-questions mailing list