1. Bon nommage
Le code source est plus à lire par les développeurs qu'à compiler par les compilateurs, donc le code source doit avoir une bonne lisibilité. Un bon nommage est un facteur clé pour rendre votre code aussi lisible que possible pour les autres.
Plus précisément : les fichiers de code source, les espaces de noms, les classes, les modèles, les fonctions, les paramètres, les noms de variables, les noms de constantes, etc. doivent tous avoir des noms significatifs et expressifs.
Si vous rencontrez des difficultés pour trouver des noms appropriés pour les variables, les classes ou les fonctions, cela indique probablement une difficulté ou un défaut de conception dans votre code, et il est temps de trouver et de résoudre la cause première de la difficulté de dénomination.
Vous trouverez ci-dessous des suggestions spécifiques pour une bonne dénomination.
1.1. Le nom doit être auto-commentaire
C'est-à-dire qu'il n'y a pas besoin de commentaires pour expliquer la signification du nom, et vous pouvez comprendre son objectif en voyant le nom.
Exemples de mauvais noms :
uint unm ;
drapeau booléen ;
Liste QList<Clients> ;
données QString ;
Bons exemples de nommage :
uint numberOfPerson ;
booléen est modifié ;
QList<Costomers> costomersList ;
Informations personnelles QString ;
Il faut veiller à ne pas utiliser de noms trop verbeux. Des noms plus courts et moins descriptifs peuvent être utilisés si le contexte de la variable est clair. Par exemple:
struct personInfo
{ QString nameOfPerson; int ageOfPerson; } ;
Sachant qu'il s'agit d'une structure d'informations sur les personnes, il est redondant d'utiliser person dans les variables, qui peuvent s'écrire :
struct personInfo
{ nom QString; int âge ; } ;
(Juste un exemple illustratif, la plupart des gens n'écrivent pas de code comme celui-ci...)
1.2, conception pilotée par le domaine
C'est-à-dire que les composants, les classes, les fonctions, etc. sont nommés d'après les concepts et les éléments du domaine d'application.
Par exemple:
class QueryStudentCourseSelection
{ public : Student identityStudent(const int StudentID) ; CourseList getAllSelectedCourseList(const int StudentID); Enseignant viewTeacherInformation(std::string professorName); } ;
Il s'agit d'une classe liée à la sélection des étudiants, et diverses définitions qu'elle contient utilisent des éléments liés au domaine de l'éducation, ce qui rend les fonctions de cette classe assez faciles à comprendre.
1.3, structure en couches
Pour une structure hiérarchique, plus la hiérarchie est profonde, plus le nom est spécifique.
class CarFactory
{ public : CarFactory(); void ProduceCars(int number); } ; class GreenCarFactory : public CarFactory { public: GreenCarFactory(); void ProduceGreenCars(int number); } ;
1.4. Éviter les noms redondants
Ces noms doivent être évités :
class Film
{ privé : QString stringTitle ; } ;
Le nom du film est une chaîne, et la chaîne devant le nom est évidemment redondante.
1.5. Évitez d'utiliser des abréviations obscures
Lorsque vous écrivez des noms de variables, vous devez utiliser des mots complets au lieu d'abréviations, ce qui augmentera la lisibilité du code.
QString PWD ;//méthode d'écriture non recommandée
Mot de passe QString ;//méthode d'écriture suggérée
1.6. Éviter d'utiliser la nomenclature hongroise
Les outils de développement d'aujourd'hui sont assez intelligents et il n'est pas nécessaire de connaître le type d'une variable à travers son nom.
1.7. Évitez d'utiliser le même nom à des fins différentes
Il peut être mal interprété par la personne qui lit le code.
2. Remarques
2.1. Principes de base
Le code doit être aussi explicite que possible, essayez de rendre le code lui-même facile à comprendre. Autrement dit, essayez de ne pas écrire de commentaires, sauf s'il s'agit d'un endroit qui nécessite des instructions spéciales.
2.2. N'écrivez pas de blocs de commentaires
Commentaire de bloc : un texte de commentaire multiligne qui explique sa fonction ou identifie les informations de copyright devant une fonction ou une classe. Ce genre de commentaire de bloc a peu de sens positif.
2.3. Situations où des commentaires doivent être écrits
Lorsqu'un morceau de code a un niveau de complexité inhérente si élevé qu'il ne peut pas être facilement compris par quelqu'un sans une expertise approfondie.
Lorsqu'il y a une dérogation délibérée aux bons principes de conception pour une raison quelconque. Par exemple, si vous avez délibérément copié un morceau de code, vous pouvez expliquer pourquoi vous l'avez fait dans les commentaires.
2.4, le principe d'annotation
Assurez-vous que les commentaires fournissent des informations importantes au lecteur du code qui ne sont souvent pas évidentes dans le code lui-même.
Il devrait expliquer pourquoi le code fait ce qu'il fait, pas comment le faire. Autrement dit, il doit expliquer pourquoi ce code existe, mais pour comprendre comment le code le fait, vous devez regarder le code lui-même plutôt que les commentaires.
Les commentaires doivent être aussi courts et expressifs que possible.
Les annotations nécessitent également une maintenance.
3. Fonction
3.1. Une fonction ne fait qu'une chose
Lorsque le code de la fonction comporte les signes suivants, vous devez envisager de scinder la fonction :
Le nombre de lignes de code de la fonction est très élevé.
Lorsque vous donnez à une fonction un nom expressif pour décrire ce que fait la fonction, les conjonctions "et" et "ou" ne peuvent pas être évitées dans le nom de la fonction.
Quand on constate que le corps fonctionnel est divisé en plusieurs parties inconsciemment.
La fonction contient un grand nombre d'instructions if-else et switch-case.
La fonction a de nombreux paramètres entrants, en particulier des paramètres de type booléen.
3.2. Rendre la fonction aussi petite que possible
Il peut y avoir beaucoup de gens qui ne sont pas d'accord ici, mais je suis d'accord avec l'auteur : la fonction doit être aussi petite que possible, idéalement quatre ou cinq lignes, au plus une douzaine de lignes.
La surcharge des appels de fonction n'est pas un problème, les compilateurs c++ modernes et leurs bonnes optimisations et leurs bons processeurs peuvent exécuter des dizaines de milliards d'instructions par seconde. C'est souvent une mauvaise architecture et une mauvaise conception qui causent vraiment des problèmes de performances, et ce n'est que dans des cas extrêmement particuliers que vous devez vous soucier de la surcharge des appels de fonction.
3.3. Paramètres de fonction et valeurs de retour
Les paramètres de fonction doivent être aussi peu nombreux que possible. De préférence aucun paramètre ou 1 paramètre, faire tout son possible pour ne pas avoir plus de 3 paramètres.
Dans la mesure du possible, les fonctions membres ne doivent avoir aucun paramètre, sauf si nécessaire. Les fonctions membres sont généralement utilisées pour manipuler l'état interne de la classe. Si la fonction membre n'utilise pas de variables membres, il est préférable de vérifier si la fonction est placée en dehors de la classe en tant que fonction indépendante.
Évitez les paramètres de drapeau. Les paramètres de type flag sont généralement de type booléen, et la fonction effectue différentes opérations selon le flag transmis. Cela viole le principe selon lequel une fonction fait une chose et la fonction doit être divisée à ce moment.
Évitez d'utiliser des paramètres de sortie (non-pointeur, non-référence) afin que la fonction renvoie plusieurs valeurs. Lorsque vous souhaitez qu'une fonction renvoie plusieurs valeurs : si les valeurs de retour ne sont pas étroitement liées, vous pouvez utiliser std::tuple ou std::pair ; et si les valeurs renvoyées sont très cohérentes, vous pouvez encapsuler traiter ces données en classes ou structures.
Évitez de renvoyer nullptr lorsqu'une fonction renvoie une variable de type pointeur. Parce qu'après avoir renvoyé nullptr, vous devrez ajouter un chemin de traitement lorsque le pointeur renvoyé est nul ou ajouter du code pour juger de l'opération nulle dans le code après avoir appelé la fonction. Solution : premièrement, la fonction crée un objet sur la pile et le renvoie, et utilise la sémantique std::move lors de la réception, ce qui évite une construction de copie coûteuse ; deuxièmement, crée un objet sur la pile avant d'appeler la fonction, puis utilise la non- référence de l'objet en tant que paramètre passé à la fonction.
3.4. Faire bon usage des qualificatifs const
La violation de const entraînera des erreurs de compilation, ce qui peut économiser du temps de débogage, et l'utilisation de const peut permettre au compilateur de prendre en charge certaines optimisations, c'est-à-dire d'améliorer les performances d'exécution du programme.
Interprétez correctement l'objet modifié par const : const modifie toujours le contenu à sa gauche, et lorsqu'il n'y a pas de contenu à gauche, il modifie le contenu à droite (le pointeur vers l'objet ou l'objet lui-même).
4. Conversion de type obligatoire
Dans la mesure du possible, évitez d'utiliser des moulages et essayez d'éliminer les problèmes de conception qui conduisent à l'utilisation de moulages.
Seuls les casts de style C++ doivent être utilisés lorsqu'ils sont inévitables, car le compilateur vérifie les casts de style C++ et non les casts de style C.
Essayez d'utiliser static_cast<>, const_cast<>, si ce n'est pas extrêmement nécessaire, n'utilisez pas reinterpret_cast<>, dynamic_cast<>
Cinq, macro
N'utilisez pas de macros, si vous souhaitez définir une constante, vous devez utiliser const.