What should and should not be in the Erlang header file (.hrl)?

Question

I am a little confused about what the .hrl file should be used .hrl . I understand that .hrl files can contain any valid Erlang code and that using the -include directive will essentially embed code in a .hrl file in any module that includes it.

What code is suitable for placement in these .hrl files, then? Erlang programming rules state the following:

If a record should be used in several modules, its definition should be placed in the header file (with the suffix .hrl), which is part of the modules.

As a result, I got the habit of doing this in my code. However, I would like to add things like the instantiation and comparison functions for the records, as well as the type definitions in my headers (since this is what I would do in C). Is this a bad shape? Should types be exported from an .erl file instead, even if they are used in multiple modules? There seems to be no documentation of best practices regarding the available Erlang headers.

Answer 1

LIke C, the include statement literally adds the contents of the included file to the erl file. Thus, including any actual code in hrl files will cause this code to be copied wherever you include it. This will result in unnecessary duplication of functions in each Erlang module.

I would put any actual Erlang code in my own erl module, as well as any record definitions, type specifications or general macros in hrl files. Record definitions and type specifications are not compiled into binary files, so you can include them in multiple files.

Answer 2

Usually you put things in .hrl that you want to share between modules, usually write definitions and macros. Things that should be purely local to the module, you do not put in the .hrl file. Thus, a purely local definition of the record, for example, the local state on the server, will not be in .hrl , but only in the module that defines the server. Same thing with macro definitions. You should always avoid unnecessarily exposing inside information.

Since the included file is directly inserted into the including file, then any code contained in it will be duplicated in each module that includes it. Usually you do not want this.

Answer 3

I use hrl files to store various fixtures for use in my unit tests. I don't like to use them in actual production code for anything. Having the same function imported in different places makes code definition difficult. It’s best to just have this code in a separate module and export it explicitly. Types can also be explicitly exported using the -export_type directive.

I don’t even like sharing records with him (although this is the only way to exchange notes). For this, I prefer the module to not control anything except this method with the corresponding get and set functions. Shared notes are a disaster awaiting the emergence and more complex code upgrades.

In short, do not use them for anything important.