Partie 1. Introduction...
Partie 8. DénominationPartie 9. Commentaires...
Lors de l'écriture de code, nous utilisons tous les règles de conception du code. Parfois, leurs propres 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 plus facilement en anglais que dans leur langue maternelle, il est plus agréable d'avoir un manuel dans cette dernière.
Cet article est une traduction d'une partie du guide de style Google en C ++ en russe.
Article original (fork sur github),
traduction mise à jour .
Nommer
Les règles de base pour le style de codage sont la dénomination. L'apparition immédiate du nom (sans rechercher d'annonce) nous dit de quoi il s'agit: type, variable, fonction, constante, macro, etc. Les règles de dénomination peuvent être arbitraires, mais la cohérence est importante et les règles doivent être suivies.
Principes généraux de dénomination
- Utilisez des noms que même les membres de l'autre équipe comprendront.
- Le nom doit parler du but ou de l'applicabilité de l'objet.
- N'économisez pas sur la longueur du nom, il vaut mieux avoir un nom plus long et plus compréhensible (même pour les débutants).
- Moins d'abréviations, surtout si elles ne sont pas familières en dehors du projet.
- N'utilisez que des abréviations connues (Wikipedia les connaît-il?).
- Ne raccourcissez pas les mots.
En général, la longueur du nom doit correspondre à la taille de la portée. Par exemple,
n est un nom approprié dans une fonction de 5 lignes, cependant, lorsque vous décrivez une classe, cela peut être un peu court.
class MyClass { public: int CountFooErrors(const std::vector<Foo>& foos) { int n = 0;
class MyClass { public: int CountFooErrors(const std::vector<Foo>& foos) { int total_number_of_foo_errors = 0;
Notez que les noms typiques sont également valides:
i pour un itérateur ou un compteur,
T pour un paramètre de modèle.
À l'avenir, lors de la description des règles, «mot» / «mot» est tout ce qui est écrit en anglais sans espaces, y compris les abréviations. En un mot, la première lettre peut être mise en majuscule (selon le style: "
camel case " ou "Pascal case"), les lettres restantes sont en minuscules. Par exemple, de préférence
StartRpc () , de
préférence StartRPC () .
Les paramètres des modèles suivent également les règles de leurs catégories: noms de types, noms de variables, etc.
Noms de fichiers
Les noms de fichiers doivent être écrits uniquement en lettres minuscules, vous pouvez utiliser un trait de soulignement (
_ ) ou un trait d'union (
- ) pour les séparer. Utilisez le séparateur utilisé dans le projet. S'il n'y a pas d'approche unique, utilisez "_".
Exemples de noms appropriés:
- my_useful_class.cc
- my-useful-class.cc
- myusefulclass.cc
- myusefulclass_test.cc // _unittest et _regtest sont déconseillés.
Les fichiers C ++ doivent se terminer par
.cc , l'en-tête doit être en
.h . Les fichiers inclus en tant que texte doivent se terminer par
.inc (voir également la section En-
têtes indépendants ).
N'utilisez pas de noms qui existent déjà dans
/ usr / include , tels que
db.h.Essayez de donner des noms spécifiques aux fichiers. Par exemple,
http_server_logs.h est meilleur que
logs.h. Lorsque les fichiers sont utilisés par paires, il est préférable de leur donner le même nom. Par exemple,
foo_bar.h et
foo_bar.cc (et contiennent la classe
FooBar ).
Noms des types
Les noms de type commencent par une majuscule, chaque nouveau mot commence également par une majuscule.
Les traits de soulignement ne sont pas utilisés:
MyExcitingClass ,
MyExcitingEnum .
Les noms de tous types - classes, structures, alias, énumérations, paramètres de modèle - sont nommés dans le même style. Les noms de type commencent par une majuscule, chaque nouveau mot commence également par une majuscule. Les tirets bas ne sont pas utilisés. Par exemple:
Noms de variables
Les noms des variables (y compris les paramètres de fonction) et des membres de données sont écrits en lettres minuscules avec un trait de soulignement entre les mots. Les membres de ces classes (et non les structures) sont complétés par un trait de soulignement à la fin du nom. Par exemple:
a_local_variable ,
a_struct_data_member ,
a_class_data_member_ .
Noms de variable communs
Par exemple:
std::string table_name;
std::string tableName;
Membres de données de classe
Les membres de ces classes, statiques et non statiques, sont appelés variables ordinaires avec l'ajout d'un trait de soulignement à la fin.
class TableInfo { ... private: std::string table_name_;
Structurer les membres de données
Les membres des données de structure, statiques et non statiques, sont appelés variables régulières. Aucun trait de soulignement ne leur est ajouté à la fin.
struct UrlTableProperties { std::string name; int num_entries; static Pool<UrlTableProperties>* pool; };
Voir aussi
Structures vs Classes , qui décrit quand utiliser les structures, quand les classes.
Noms des constantes
Les objets sont déclarés constexpr ou const, de sorte que la valeur ne change pas pendant l'exécution. Les noms des constantes commencent par le symbole "k", puis vient le nom dans un style mixte (lettres majuscules et minuscules). Le soulignement peut être utilisé dans de rares cas où les lettres majuscules ne peuvent pas être utilisées pour la séparation. Par exemple:
const int kDaysInAWeek = 7; const int kAndroid8_0_0 = 24;
Tous les objets constants similaires avec un type de stockage statique (c'est-à-dire statique ou global, pour plus de détails ici:
Durée de stockage ) sont également nommés. Cette convention est facultative pour les variables d'autres types de stockage (par exemple, les objets constants automatiques).
Noms des fonctions
Les fonctions communes sont nommées dans un style mixte (majuscules et minuscules); les fonctions d'accès aux variables (accesseur et mutateur) doivent avoir un style similaire à la variable cible.
En règle générale, un nom de fonction commence par une lettre majuscule et chaque mot du nom est mis en majuscule.
void AddTableEntry(); void DeleteUrl(); void OpenFileOrDie();
(Des règles similaires s'appliquent aux constantes dans une zone de classe ou d'espace de noms qui font partie de l'API et doivent ressembler à des fonctions (et le fait qu'elles ne soient pas des fonctions n'est pas critique))
Les accesseurs et les mutateurs (fonctions get et set) peuvent être nommés comme les variables correspondantes. Ils correspondent souvent à de vraies variables membres, mais ce n'est pas nécessaire. Par exemple,
int count () et
void set_count (int count) .
Espace de noms Espace de noms
L'espace de noms est appelé en minuscules. L'espace de noms de niveau supérieur est basé sur le nom du projet. Évitez les collisions de vos noms et d'autres espaces de noms bien connus.
Un espace de noms de niveau supérieur est généralement le nom d'un projet ou d'une équipe (qui a créé le code). Le code doit être situé dans un répertoire (ou sous-répertoire) avec un nom correspondant à l'espace de noms.
N'oubliez pas la règle de
ne pas utiliser d'abréviations - cela s'applique également aux espaces de noms. Il est peu probable que le code à l'intérieur nécessite une référence d'espace de noms, les abréviations sont donc superflues.
Évitez d'utiliser des noms connus pour les espaces de noms imbriqués. Les collisions entre noms peuvent créer des surprises lors de l'assemblage. En particulier, ne créez pas d'espaces de noms imbriqués nommés
std . Des identifiants de projet uniques (
websearch :: index ,
websearch :: index_util ) sont
recommandés au lieu d'être dangereux contre les collisions
websearch :: util .
Pour
les espaces de noms
internes / internes , des collisions peuvent se produire lorsqu'un autre code est ajouté (les assistants internes ont tendance à se répéter sur différentes équipes). Dans ce cas, l'utilisation d'un nom de fichier pour nommer un espace de noms aide beaucoup. (
websearch :: index :: frobber_internal à utiliser dans
frobber.h )
Noms d'énumération
Les énumérations (à la fois avec des contraintes de portée et sans contraintes de portée) doivent être appelées
constantes ou
macros . C'est-à-dire:
kEnumName ou
ENUM_NAME .
Il est préférable de nommer les valeurs individuelles de l'énumérateur sous forme de constantes. Cependant, il est permis de se référer à des macros. Le nom de l'
énumération UrlTableErrors (et
AlternateUrlTableErrors )
lui -
même est un type. Par conséquent, un style mixte est utilisé.
enum UrlTableErrors { kOk = 0, kErrorOutOfMemory, kErrorMalformedInput, }; enum AlternateUrlTableErrors { OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2, };
Jusqu'en janvier 2009, le style de dénomination des valeurs d'énumération était semblable à celui des macros. Cela a créé des problèmes avec les noms de macro et les valeurs d'énumération en double. L'application d'un style constant résout le problème et il est préférable d'utiliser un style constant dans le nouveau code. Cependant, il n'est pas nécessaire de réécrire l'ancien code (tant qu'il n'y a pas de problème de duplication).
Noms de macro
Tu ne vas pas
définir des macros ? Juste au cas où (si vous y allez), ils devraient ressembler à ceci:
MY_MACRO_THAT_SCARES_SMALL_CHILDREN_AND_ADULTS_ALIKE .
Veuillez lire comment
définir des macros ; Normalement, les macros
ne doivent
pas être utilisées. Cependant, si vous en avez absolument besoin, nommez-les en majuscules avec des traits de soulignement.
#define ROUND(x) ... #define PI_ROUNDED 3.0
Exceptions de dénomination
Si vous devez nommer quelque chose qui a des analogues dans le code C ou C ++ existant, suivez le style utilisé dans le code.
bigopen ()nom de fonction dérivé de
open ()uintdéfinition similaire aux types standard
bigposstruct ou
classe dérivée de
possparse_hash_mapEntité de type STL; suivre le style stl
LONGLONG_MAXconstante comme
INT_MAXRemarque: Les liens peuvent conduire à des sections du manuel qui n'ont pas encore été traduites.