Les éléments les plus importants d'une norme de codage C++ légère

Question

J'ai participé à l'élaboration de normes de codage assez élaborées. D'après ma propre expérience, il est difficile de les faire respecter si l'on ne dispose pas de processus appropriés pour les maintenir et de stratégies pour les faire respecter.

Aujourd'hui, je travaille et je dirige un environnement où il est encore moins probable que des processus et des stratégies de suivi soient mis en place depuis longtemps. Je veux néanmoins maintenir un niveau minimum de code respectable. J'ai donc pensé que je pourrais obtenir de bonnes suggestions ici, et que nous pourrions ensemble produire un sous-ensemble raisonnable et léger des pratiques standard de codage les plus importantes pour que d'autres puissent l'utiliser comme référence.

Donc, pour souligner l'essentiel ici :

Quels éléments d'une norme de codage C++ sont les plus importants à respecter ?

• Règles de réponse/vote

  • 1 candidat par réponse, de préférence avec un bref motivation.

  • Vote négatif candidats qui se concentrent sur le style et les directives de formatage subjectives. Il ne s'agit pas d'indiquer qu'elles sont sans importance, mais seulement qu'elles sont moins pertinentes dans ce contexte.

  • Vote négatif les candidats se concentrant sur la manière de commenter/documenter le code. Il s'agit d'un sujet plus vaste qui pourrait même mériter son propre billet.

  • Votez pour des candidats qui facilitent clairement un code plus sûr, qui minimise le risque de bogues énigmatiques, qui augmente la maintenabilité, etc.

  • Ne votez pas dans n'importe quelle direction sur les candidats dont vous avez des doutes. Même s'ils semblent raisonnables et intelligents, ou au contraire "quelque chose que personne n'utiliserait", votre vote doit être basé sur une compréhension claire et une expérience.

Answer 1

Quelles que soient les directives, faites-les très fácil pour reconnaître l'applicabilité : moins vous avez de choix, moins vous perdez de temps à choisir. Et plus il devient facile de décortiquer le code.

Exemples de "difficile à reconnaître" :

• Pas d'accolades si une seule ligne dans le corps conditionnel
• Utiliser le placement des accolades K&R pour les espaces de noms, mais mettre des accolades sous les conditions dans le code de définition des fonctions
• ...

Answer 2

Un point devrait être consacré à l'explication de la différence entre la sémantique des valeurs et la sémantique des entités. Il pourrait fournir les extraits de code typiques sur la façon dont la copie est traitée dans les différents cas.

Voir aussi Liste de contrôle pour l'écriture d'un constucteur de copie et d'un opérateur d'assignation en C++.

Answer 3

C'est probablement une évidence, mais c'est néanmoins une règle importante :

Évitez les comportements indéfinis.

Il y en a énormément en C++, et il est probablement impossible d'écrire une application non triviale qui n'en dépende pas d'une manière ou d'une autre, mais la règle générale devrait toujours être "un comportement non défini est mauvais". (Parce que malheureusement, il existe des programmeurs C++ qui pensent que "ça marche sur ma machine/ mon compilateur" est suffisant).

Si vous devez y avoir recours, faites en sorte que tout le monde sache clairement quoi, pourquoi, où et comment.

Answer 4

Passe les arguments d'entrée par référence const, et les arguments de sortie ou d'entrée-sortie par pointeur. Il s'agit d'une règle tirée du guide de style de Google.

J'avais auparavant une aversion absolue pour les pointeurs et je préférais utiliser des références chaque fois que cela était possible (comme l'a suggéré l'une des affiches de ce fil de discussion). Cependant, l'adoption de cette convention output-arg-as-pointer a rendu mes fonctions beaucoup plus lisibles. Par exemple,

SolveLinearSystem(left_hand_side, right_hand_side, &params);

indique clairement que l'on écrit sur "params".

Answer 5

Les accolades sont nécessaires si vous avez plus d'une étape d'indentation :

if (bla) {
  for (int i = 0; i < n; ++i)
    foo();
}

Cela permet de conserver une indentation conforme à la façon dont le compilateur voit le code.