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

Ne jamais utiliser de structs sans constructeurs appropriés

Les structs sont des constructions C++ légales, utilisées pour regrouper des données. Néanmoins, les données doivent toujours être initialisées correctement.

Tous les structs C++ devraient avoir au moins un constructeur par défaut, qui définira ses données agrégées aux valeurs par défaut.

struct MyStruct // BAD
{
   int i ; bool j ; char * k ;
}

struct MyStruct // GOOD
{
   MyStruct() : i(0), j(true), k(NULL) : {}

   int i ; bool j ; char * k ;
}

Et s'ils sont habituellement initialisés d'une manière ou d'une autre, fournissez un constructeur pour permettre à l'utilisateur d'éviter l'initialisation d'une structure de style C :

MyStruct oMyStruct = { 25, true, "Hello" } ; // BAD
MyStruct oMyStruct(25, true, "Hello") ;      // GOOD

Comment cela facilite clairement un code plus sûr, qui minimise le risque de bogues énigmatiques, qui augmente la maintenabilité, etc ?

Avoir une structure sans un constructeur approprié laisse à l'utilisateur de cette structure la tâche de l'initialiser. Ainsi, le code suivant sera copié collé de fonction en fonction :

void doSomething()
{
   MyStruct s = { 25, true, "Hello" } ;
  // Etc.
}

void doSomethingElse()
{
   MyStruct s = { 25, true, "Hello" } ;
  // Etc.
}

// Etc.

Ce qui signifie qu'en C++, si vous devez ajouter un champ dans la structure, ou changer l'ordre des données internes, vous devez passer par toutes ces initialisations pour vérifier que chacune est toujours correcte. Avec un constructeur approprié, la modification des données internes de la structure est découplée de son utilisation.

Answer 2

N'ajoutez pas de types ou de fonctions à l'espace de noms global.

Answer 3

Principe de la moindre surprise .

Ce n'est peut-être pas la "saveur" des règles que vous recherchez, mais je le mettrais certainement en premier.

Il s'agit non seulement de la racine, de la raison et de la vérification de l'équilibre de toutes les choses ennuyeuses comme le formatage et les directives de commentaire, mais aussi - et c'est plus important pour moi - de mettre l'accent sur la lecture et la compréhension du code, plutôt que sur sa simple compilation.

Il couvre également la seule mesure raisonnable de la qualité du code que j'ai jamais rencontrée : la mesure de la qualité du code. WTF par minute .

J'utiliserais ce premier point pour souligner l'importance et la valeur d'un code clair et cohérent, et pour motiver les éléments suivants de la norme de codage.

Answer 4

Interdire t[i]=i++; f(i++,i); et ainsi de suite, car il n'existe aucune garantie (portable) concernant ce qui est exécuté en premier.

Answer 5

Toujours, toujours, toujours faire une initialisation correcte des membres de données lors de la construction d'un objet.

J'ai rencontré un problème où un constructeur d'objet s'appuyait sur une initialisation "par défaut" pour ses membres de données. La construction du code sous deux plateformes (Windows/Linux) a donné des résultats différents et un bug de mémoire difficile à trouver. Le résultat était qu'un membre de données n'était pas initialisé dans le constructeur, et utilisé avant qu'il ne soit initialisé. Sur une plate-forme (Linux), le compilateur l'a initialisé à la valeur par défaut que le rédacteur du code pensait appropriée. Sous Windows, la valeur a été initialisée à quelque chose, mais à un déchet. Lors de l'utilisation du membre de données, tout s'est détraqué. Une fois l'initialisation corrigée, plus de problème.