Ordine file di intestazione C

Naviga le tue risposte
6

In molti progetti ed esempi vedo che gli include locali sono elencati prima delle librerie esterne e prima dei file di intestazione per la funzionalità del compilatore integrata.

C'è qualche vantaggio qui che mi manca?

Ho sempre usato il seguente modello: 

1) built in header files
2) External lib header file
   A) External lib dependent on previous lib header file
3) custom project libs
4) local project header files

Ad esempio: 

#include <stdio.h>
#include <stdlib.h>

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <SDL2/SDL_ttf.h>

#include "DisplayInfo.h"

#include "projectModule.h"

È una pratica sbagliata o cattiva?

    
posta Joe 23.07.2016 - 11:31
fonte

2 risposte

8

Is there any advantage here that I am missing?

Sì, c'è. Io, insieme a un gran numero di progetti software, usavo seguire la pratica descritta nella domanda. Molti progetti, compresi quelli moderni su cui lavoro, ora adottano l'approccio opposto in un file sorgente:

  1. Il file di intestazione che dichiara le funzioni definite nel file sorgente è il primo che è incluso.
  2. Altri file di intestazione dello stesso progetto sono inclusi di seguito.
  3. I file di intestazione di progetti non standard (ad esempio, eigen, boost, Qt) sono inclusi dopo le intestazioni locali.
  4. Infine, i file di intestazione standard sono inclusi per ultimi.
  5. Le inclusioni fuori ordine devono essere chiaramente documentate in merito al motivo per cui l'intestazione non è stata inclusa nell'ordine sopra.


Idealmente, tutti i file di intestazione dovrebbero essere autonomi e l'ordine di inclusione non dovrebbe avere importanza. In pratica, le persone spesso scrivono file di intestazione che non sono autonomi, e talvolta l'ordine di inclusione conta. Per combattere il primo problema, il primo file incluso è il file di intestazione che dichiara che le funzioni che si stanno definendo in un file sorgente creano un bel test che un file di intestazione è effettivamente autosufficiente. Errori di compilazione che risultano dal primo file incluso significa che c'è un bug in quell'intestazione.

Per combattere il secondo problema (un'inclusione fuori servizio è necessaria), questo dovrebbe essere visto come un odore di codice. Se l'odore del codice è nel tuo codice progetto, la cosa migliore da fare è correggerlo. Gli odori di codice sono a volte un maleodorante necessario. Supponiamo, ad esempio, di utilizzare quella che altrimenti sarebbe una grande libreria di terze parti se non fosse per il fatto che i suoi file di intestazione non sono autonomi. Si utilizza la libreria perché tutte le alternative sono peggiori, ma si documentano le inclusioni fuori ordine.

Quest'ultimo problema sta diventando più raro in quanto i progetti adottano pratiche di inclusione interne (prima locale, ultimo sistema). Questo ordine di inclusione vecchio stile fa male alla qualità del software.

    
risposta data 23.07.2016 - 15:34
fonte
1

No, il tuo ordine di include non è una cattiva pratica.

Un vantaggio nel mettere il file di intestazione locale per primo, specialmente il file che dichiara le funzioni la cui definizione è nel file corrente, è che puoi assicurarti che i tuoi file di intestazione siano autonomi (non dipendono da nessun altro file di intestazione inclusi prima di loro).

Oltre a ciò, l'ordine degli include è principalmente una questione di abitudini locali e gusti personali.

    
risposta data 23.07.2016 - 14:02
fonte

Leggi altre domande sui tag

C'è qualche differenza tra il casting e il call .Value in oggetti NullableT? Il modo migliore per fare l'autorizzazione lato client per un'applicazione JavaScript a pagina singola?