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

L'optimisation prématurée est la racine de tous les maux

Écrivez d'abord un code sûr et correct.

Ensuite, si vous avez des problèmes de performance, et si votre profileur vous a dit que le code est lent, vous pouvez essayer de l'optimiser.

Ne croyez jamais que vous pourrez optimiser des bouts de code mieux que le compilateur.

Lorsque vous recherchez des optimisations, étudiez les algorithmes utilisés, et les alternatives potentiellement meilleures.

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

En général, le code "optimisé" (ou prétendument optimisé) est beaucoup moins clair et a tendance à s'exprimer de manière brute, proche de la machine, au lieu d'une manière plus orientée métier. Certaines optimisations reposent sur des commutateurs, des ifs, etc., et seront alors plus difficiles à tester en raison des multiples chemins de code.

Et bien sûr, l'optimisation avant le profilage conduit souvent à un gain de performance nul.

Answer 2

Des accolades pour toute instruction de contrôle. (Grâce à ma propre expérience et renforcée par la lecture de Code Complete v2) :

// bad example - what the writer wrote
if( i < 0 ) 
    printf( "%d\n", i );
    ++i; // this error is _very_ easy to overlook!  

// good example - what the writer meant
if( i < 0 ) {
    printf( "%d\n", i );
    ++i;
}

Answer 3

Préférez un code conforme aux normes. Préférer utiliser les bibliothèques standard.

Answer 4

Seule une utilisation triviale de l'opérateur ? :, à savoir

float x = (y > 3) ? 1.0f : -1.0f;

c'est bon, mais ça ne l'est pas :

float x = foo(2 * ((y > 3) ? a : b) - 1);

Answer 5

Utilisez un outil de lint - par exemple PC-Lint. Cela permettra de détecter la plupart des problèmes liés aux directives de codage "structurelles". Il s'agit de choses qui se traduisent par des bogues réels plutôt que par des problèmes de style ou de lisibilité. (Non pas que la lisibilité ne soit pas importante, mais elle l'est moins que les erreurs réelles).

Exemple, plutôt que d'exiger ce style :

if (5 == variable)

Pour éviter le bogue de l'affectation involontaire, laissez lint le trouver.