Cosa dovrebbe e non dovrebbe essere in un file di intestazione Erlang (.hrl)?

Question

Sono un po 'confuso su cosa dovrebbe essere usato un file .hrl. È a mia conoscenza che i file .hrl possono contenere qualsiasi codice Erlang valido e che l'utilizzo della direttiva -include essenzialmente inserirà il codice nel file in qualsiasi modulo che lo include.

Che tipo di codice è appropriato inserire in questi file .hrl, quindi? norme di programmazione di Erlang affermano quanto segue per quanto riguarda i record:

Se il record deve essere utilizzato in diversi moduli, la sua definizione deve essere collocato in un file di intestazione (con il suffisso .hrl) che è incluso dai moduli.

Come risultato, ho preso l'abitudine di farlo nel mio codice. Comunque, mi piace mettere cose come le istanze e le funzioni di confronto per i record, così come le definizioni dei tipi, anche nelle intestazioni (dato che questo è il genere di cose che farei in C). È questa brutta forma? I tipi dovrebbero essere esportati da un file .erl, anche se sono utilizzati in più moduli? Non sembra esserci alcuna documentazione sulle migliori pratiche relative alle intestazioni di Erlang disponibili.

Answer 1

LIke C, l'istruzione include aggiunge letteralmente il contenuto del file incluso nel file erl. Pertanto, inserendo qualsiasi codice effettivo nei file hrl, il codice verrà copiato ovunque sia incluso. Ciò porterebbe a duplicazioni inutili di funzionalità in ogni modulo di Erlang.

Inserirò qualsiasi codice Erlang nel proprio modulo erl e qualsiasi definizione di record, specifiche di tipo o macro comuni nei file hrl. Le definizioni dei record e le specifiche del tipo non sono compilate nei file binari, quindi sono sicuri da includere in più file.

Answer 2

Uso i file hrl per archiviare vari dispositivi da utilizzare nei test dell'unità. Non mi piace usarli nel codice di produzione attuale per qualsiasi cosa. Avere la stessa funzione importata in posizioni diverse rende difficile ragionare sul codice. È preferibile semplicemente avere quel codice in un modulo separato ed esportarlo esplicitamente. I tipi possono anche essere esportati esplicitamente con la direttiva -export_type.

Non mi piace nemmeno condividere i record con esso (anche se questo è l'unico modo per condividere i record). Per questo, preferisco che un modulo non gestisca altro che quel metodo con le funzioni get e set appropriate. I record condivisi sono un disastro in attesa di accadere e rendono più complicati gli aggiornamenti del codice.

In breve, non usarli per qualcosa di importante.

Answer 3

In genere si inseriscono le cose in un .hrl che si desidera condividere tra i moduli, in genere le definizioni e le macro dei record. Cose che devono essere puramente locali a un modulo che non inseriresti in un file .hrl. Quindi una definizione di record puramente locale, ad esempio lo stato locale in un server, non andrebbe in un .hrl ma solo nel modulo che definisce il server. Lo stesso con le definizioni di macro. Evitare sempre di esporre inutilmente le informazioni interne.

Poiché il file di inclusione viene inserito direttamente nel file incluso, qualsiasi codice contenuto in esso verrà duplicato in ciascun modulo che lo include. Generalmente non vuoi farlo.