O que deve e o que não deve estar em um arquivo de cabeçalho? [fechadas]

Que coisas absolutamente nunca devem ser incluídas em um arquivo de cabeçalho?

Se, por exemplo, estou trabalhando com um formato padrão do setor documentado que possui muitas constantes, é uma boa prática defini-las em um arquivo de cabeçalho (se estou escrevendo um analisador para esse formato)?

Quais funções devem entrar no arquivo de cabeçalho?
Que funções não deveriam?

O que colocar nos cabeçalhos:

• O conjunto mínimo de #includediretivas necessárias para tornar o cabeçalho compilável quando o cabeçalho é incluído em algum arquivo de origem.
• Definições de símbolo do pré-processador de coisas que precisam ser compartilhadas e que só podem ser realizadas através do pré-processador. Mesmo em C, os símbolos do pré-processador são melhor reduzidos ao mínimo.
• Encaminhar declarações de estruturas necessárias para tornar compiláveis ​​as definições de estrutura, protótipos de função e declarações de variáveis ​​globais no corpo do cabeçalho.
• Definições de estruturas de dados e enumerações compartilhadas entre vários arquivos de origem.
• Declarações para funções e variáveis ​​cujas definições serão visíveis para o vinculador.
• Definições de função em linha, mas tome cuidado aqui.

O que não pertence a um cabeçalho:

• #includeDiretivas gratuitas . Essas inclusões gratuitas causam recompilação de coisas que não precisam ser recompiladas e às vezes podem fazer com que o sistema não seja compilado. Não #includeum arquivo em um cabeçalho se o próprio cabeçalho não precisar desse outro arquivo de cabeçalho.
• Símbolos do pré-processador cuja intenção pode ser alcançada por algum mecanismo, qualquer mecanismo, exceto o pré-processador.
• Muitas e muitas definições de estrutura. Divida-os em cabeçalhos separados.
• Definições em linha de funções que exigem um adicional #include, que estão sujeitas a alterações ou que são grandes demais. Essas funções em linha devem ter pouca ou nenhuma ventilação e, se houver, devem ser localizadas nos itens definidos no cabeçalho.

O que constitui o conjunto mínimo de #includedeclarações?

Isso acaba sendo uma questão não trivial. Uma definição de TL; DR: um arquivo de cabeçalho deve incluir os arquivos de cabeçalho que definem diretamente cada um dos tipos usados ​​diretamente ou que declaram diretamente cada uma das funções usadas no arquivo de cabeçalho em questão, mas não devem incluir mais nada. Um ponteiro ou tipo de referência C ++ não se qualifica como uso direto; referências futuras são preferidas.

Há um lugar para uma #includediretiva gratuita , e isso é em um teste automatizado. Para cada arquivo de cabeçalho em um pacote de software, eu automaticamente giro e compilo o seguinte:

#include "path/to/random/header_under_test"
int main () { return 0; }

A compilação deve estar limpa (ou seja, livre de avisos ou erros). Avisos ou erros relacionados a tipos incompletos ou desconhecidos significam que o arquivo de cabeçalho em teste tem algumas #includediretivas ausentes e / ou declarações avançadas. Observe bem: Só porque o teste passa não significa que o conjunto de #includediretivas seja suficiente, muito menos o mínimo.

Além do que já foi dito.

Os arquivos H devem sempre conter:

• Documentação do código fonte !!! No mínimo, qual é o objetivo dos vários parâmetros e valores de retorno das funções.
• Protetores de cabeçalho, #ifndef MYHEADER_H #definir MYHEADER_H ... #endif

Os arquivos H nunca devem conter:

• Qualquer forma de alocação de dados.
• Definições de funções. Funções embutidas podem ser uma exceção rara em alguns casos.
• Qualquer coisa rotulada static.
• Typedefs, #defines ou constantes que não têm relevância para o restante do aplicativo.

(Eu também diria que nunca há motivo para usar variáveis ​​globais / externas não constantes, em qualquer lugar, mas isso é uma discussão para outro post.)

Eu provavelmente nunca diria nunca, mas as instruções que geram dados e código à medida que são analisadas não devem estar em um arquivo .h.

Macros, funções embutidas e modelos podem parecer dados ou código, mas não geram código à medida que são analisados, mas quando são usados. Esses itens geralmente precisam ser usados ​​em mais de um .c ou .cpp, para que pertençam ao .h.

Na minha opinião, um arquivo de cabeçalho deve ter a interface prática mínima para um correspondente .c ou .cpp. A interface pode incluir #defines, classe, typedef, definições de estrutura, protótipos de função e definições externas menos preferidas para variáveis ​​globais. No entanto, se uma declaração for usada em apenas um arquivo de origem, provavelmente ela deve ser excluída do arquivo .he deve estar contida no arquivo de origem.

Alguns podem discordar, mas meu critério pessoal para arquivos .h é que eles #incluem todos os outros arquivos .h que precisam ser capazes de compilar. Em alguns casos, pode haver muitos arquivos, portanto, temos alguns métodos eficazes para reduzir dependências externas, como declarações de encaminhamento para classes, que permitem usar ponteiros para objetos de uma classe sem incluir o que poderia ser uma grande árvore de arquivos de inclusão.

O arquivo de cabeçalho deve ter a seguinte organização:

• tipo e definições constantes
• declarações de objetos externos
• declarações de função externa

Os arquivos de cabeçalho nunca devem conter definições de objeto, apenas definições de tipo e declarações de objeto.

Instruções que geram dados e código à medida que são analisadas, não devem estar em um .harquivo. No que diz respeito ao meu ponto de vista, um arquivo de cabeçalho deve ter apenas a interface prática mínima para um .cou .cpp.