Guide de style C ++ de Google. Partie 2

Partie 1. Introduction

Partie 2. Fichiers d'en-tête

...





Lors de l'écriture de code, nous utilisons tous les règles de formatage du code. Parfois, des règles sont inventées, dans d'autres cas des guides de style prêts à l'emploi sont utilisés. Bien que tous les programmeurs C ++ lisent l'anglais plus facilement que le natif, il est plus agréable d'avoir un manuel dans ce dernier.

Cet article est une traduction d'une partie du guide de style C ++ de Google en russe.

Article original (fork sur github), traduction mise à jour .

Fichiers d'en-tête

Il est souhaitable que chaque fichier source .cc ait un fichier d'en-tête .h correspondant . Il existe également des exceptions connues à cette règle, telles que les tests unitaires ou les petits fichiers .cc contenant uniquement la fonction main () .



L'utilisation correcte des fichiers d'en-tête peut avoir un impact énorme sur la lisibilité, la taille et les performances de votre code.



Les règles suivantes vous aideront à éviter les problèmes fréquents avec les fichiers d'en-tête.

Fichiers d'en-tête indépendants

Les fichiers d'en-tête doivent être autonomes (en termes de compilation) et avoir l'extension .h . Les autres fichiers (sans en-tête) destinés à être inclus dans le code doivent avoir l'extension .inc et être associés au code d'inclusion.



Tous les fichiers d'en-tête doivent être autonomes. Les utilisateurs et les outils de développement ne doivent pas dépendre de dépendances spéciales lors de l'utilisation du fichier d'en-tête. Le fichier d'en-tête doit être verrouillable et inclure tous les fichiers requis.



Il est préférable de placer les définitions des modèles et des fonctions en ligne dans le même fichier avec leurs déclarations. Et ces définitions doivent être incluses dans chaque .ccles utiliser, sinon il peut y avoir des erreurs de lien sur certaines configurations de construction. Si les déclarations et définitions se trouvent dans des fichiers différents, l'un doit inclure l'autre. Ne séparez pas les définitions dans des fichiers d'en-tête séparés ( -inl.h ). Auparavant, cette pratique était très populaire, maintenant elle n'est plus souhaitable.



Par exception, si toutes les variantes d'arguments de modèle disponibles sont créées à partir du modèle, ou si le modèle implémente des fonctionnalités utilisées par une seule classe, il est alors permis de définir le modèle dans un (et un seul) fichier .cc , dans lequel ce modèle est utilisé.



Il existe de rares situations où le fichier d'en-tête n'est pas autonome. Cela peut se produire lorsqu'un fichier est inclus dans un emplacement non standard, par exemple au milieu d'un autre fichier. Dans ce cas, il se peut qu'il n'y ait pas de verrou de réactivation et des fichiers d'en-tête supplémentaires peuvent ne pas être inclus non plus. Nommez ces fichiers avec l'extension .inc . Utilisez-les par paires et essayez de répondre le plus possible aux exigences générales.

Redémarrer le verrouillage

Tous les fichiers d'en-tête doivent être #define protégés contre la ré-inclusion . Le format de définition de la macro doit être: <PROJET> _ <CHEMIN> _ <FICHIER> _H_ .



Pour garantir l'unicité, utilisez les composants de chemin de fichier complet dans l'arborescence du projet. Par exemple, le fichier foo / src / bar / baz.h dans le projet foo peut avoir le verrou suivant:

#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif  // FOO_BAR_BAZ_H_

Annonce préliminaire

Si possible, n'utilisez pas d'annonces anticipées. #Incluez plutôt les fichiers d'en-tête requis.



Définition La

"pré-déclaration" est une déclaration d'une classe, d'une fonction, d'un modèle sans définition correspondante.



Par

• . #include ( ) .
• . #include - .

• , .
• API, . , API: , , .
• std:: .
• , : #include. , #include ( ) :
  
  
  
  

        // b.h:
        struct B {};
        struct D : B {};
        // good_user.cc:
        #include "b.h"
        void f(B*);
        void f(void*);
        void test(D* x) { f(x); }  // calls f(B*)
        

  
  
  #include B D, test() f(void*).
• , .
• Une structure de code qui permet une déclaration préliminaire (et, en outre, l'utilisation de pointeurs comme membres de classe) peut rendre le code confus et lent.

Verdict

• Essayez d'éviter de pré-déclarer les entités déclarées dans un autre projet.
• Lorsque vous utilisez une fonction déclarée dans un fichier d'en-tête, #incluez toujours ce fichier.
• Lors de l'utilisation d'un modèle de classe, il est préférable de #inclure son fichier d'en-tête.

Consultez également les règles d'inclusion dans les noms et l'ordre d'inclusion .

Fonctions en ligne

Définissez les fonctions en tant que fonctions en ligne uniquement lorsqu'elles sont petites, par exemple pas plus de 10 lignes.



Définition



Vous pouvez déclarer des fonctions comme étant en ligne et dire au compilateur de les inclure directement dans le code appelant, en plus de la manière standard d'appeler une fonction.



Avantages L'



utilisation des fonctions en ligne peut générer un code plus efficace, en particulier lorsque les fonctions sont petites. Utilisez cette fonction pour les fonctions get / set, d'autres fonctions courtes et critiques pour les performances.



Contre



La surutilisation des fonctions en ligne peut ralentir le programme. En outre, les fonctions en ligne, en fonction de leur taille, peuvent augmenter ou diminuer la taille du code. S'il s'agit de petites fonctions, le code peut être réduit. Si la fonction est volumineuse, la taille du code peut augmenter considérablement. Notez que sur les processeurs modernes, le code allégé s'exécute plus rapidement grâce à une meilleure utilisation du cache d'instructions.



Verdict



Une bonne règle de base est de ne pas rendre les fonctions insérables si elles dépassent 10 lignes de code. Évitez de créer des destructeurs en ligne, car ils peuvent implicitement contenir beaucoup de code supplémentaire: des appels à des destructeurs de variables et des classes de base!



Une autre bonne règle de base est que cela n'a généralement pas de sens pour les fonctions en ligne qui ont des boucles ou des instructions de commutation (sauf dans les cas dégénérés où la boucle ou d'autres instructions ne sont jamais exécutées).



Il est important de comprendre qu'une fonction en ligne ne sera pas nécessairement compilée en code de cette façon. Par exemple, les fonctions généralement virtuelles et récursives sont compilées avec un appel standard. En général, les fonctions récursives ne doivent pas être déclarées comme des fonctions en ligne. La principale raison de faire des fonctions virtuelles en ligne est de placer la définition (code) dans la définition de classe elle-même (pour documenter le comportement ou la lisibilité) - souvent utilisée pour les fonctions get / set.

Noms et ordre d'inclusion

Insérez les fichiers d'en-tête dans l'ordre suivant: fichier apparié (par exemple, foo.h - foo.cc), fichiers système C, bibliothèque standard C ++, autres bibliothèques, vos fichiers de projet.



Tous les en-têtes de projet doivent être relatifs au répertoire source du projet sans utiliser d'alias UNIX tels que . (répertoire courant) ou .. (répertoire parent). Par exemple, google-awesome-project / src / base / logging.h doit être inclus comme suit :

#include "base/logging.h"

Autre exemple: si la fonction principale des fichiers dir / foo.cc et dir / foo_test.cc est d'implémenter et de tester le code déclaré dans dir2 / foo2.h , alors écrivez les fichiers d'en-tête dans l'ordre suivant:

1. dir2 / foo2.h .
2. —
3. C (: .h), <unistd.h>, <stdlib.h>.
4. —
5. C++ ( ), <algorithm>, <cstddef>.
6. —
7. .h .
8. .h .

Séparez chaque groupe (non vide) de fichiers par une ligne vide.



Cet ordre des fichiers vous permet de détecter des erreurs lorsque les fichiers d'en-tête requis (système, etc.) sont manquants dans le fichier d'en-tête apparié ( dir2 / foo2.h ) et que l'assemblage des fichiers correspondants dir / foo.cc ou dir / foo_test.cc échouera. En conséquence, l'erreur apparaîtra immédiatement au développeur travaillant avec ces fichiers (et non à une autre équipe qui utilise uniquement une bibliothèque externe).



Habituellement, les fichiers associés dir / foo.cc et dir2 / foo2.h se trouvent dans le même répertoire (par exemple, base / basictypes_test.cc et base / basictypes.h ), bien que cela ne soit pas obligatoire.



Notez que les fichiers d'en-tête C tels que stddef.h sont généralement interchangeables avec les fichiers C ++ correspondants ( cstddef ). Toute variante peut être utilisée, mais il est préférable de suivre le style du code existant.



Dans chaque section, les fichiers d'en-tête sont mieux classés par ordre alphabétique. Notez que le code précédemment écrit peut ne pas suivre cette règle. Si possible (par exemple, lors de la correction d'un fichier), corrigez l'ordre des fichiers vers le bon.



Tous les fichiers d'en-tête qui déclarent les types souhaités doivent être inclus, sauf lorsqu'ils ont été précédemment déclarés . Si votre code utilise des types de bar.h , ne comptez pas sur un autre fichier foo.h pour inclure bar.het vous pouvez vous limiter à n'inclure que foo.h : include bar.h explicitement (à moins qu'il ne soit explicitement indiqué (peut-être dans la documentation) que foo.h vous donnera également les types de bar.h ).



Par exemple, la liste des fichiers d'en - tête dans google-awesome-project / src / foo / internal / fooserver.cc pourrait ressembler à ceci:

#include "foo/server/fooserver.h"
#include <sys/types.h>
#include <unistd.h>
#include <string>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/server/bar.h"

Exceptions



Il existe des cas où vous devez inclure des fichiers d'en-tête en fonction des conditions du préprocesseur (par exemple, en fonction du système d'exploitation utilisé). Essayez de garder cette inclusion aussi courte (localisée) que possible et placez-la après les autres fichiers d'en-tête. Par exemple:

#include "foo/public/fooserver.h"
#include "base/port.h"  // For LANG_CXX11.
#ifdef LANG_CXX11
#include <initializer_list>
#endif  // LANG_CXX11

Remarques:



Image tirée de l' open source .