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

Je pense qu'un document standard de codage n'est pas la solution à ce problème. La solution est de motiver votre personnel à apprendre/se soucier du côté humain du codage - "coder pour les gens d'abord et les ordinateurs ensuite".

Il est évidemment impossible de licencier ceux qui ne se soucient pas de la situation, mais un document standard ne les aidera pas beaucoup non plus.

Answer 2

Je suggère d'exiger simplement des développeurs qu'ils lisent un tas de directives, ainsi que les livres C++ efficace et C++ plus efficace de Meyers.

Si vous voulez de la légèreté, vous allez devoir faire appel au bon sens et à un idéal commun.

Les examens de code contribuent également à faire respecter cette règle.

Pour rester léger, j'éviterais un document et une police du code. Louez publiquement le bon code.

EDIT - J'ai commencé par un commentaire ici, mais je vais le mettre dans la réponse pour faciliter la consultation :

Les examens faits correctement feront des merveilles - mais vous ne pouvez pas autoriser les hiérarchies de rapport dans l'examen et aucune statistique avec les noms des personnes ne peut être sur les résultats de l'examen.

Veillez à ce que le document soit de taille réduite et donnez des RAISONS à la "règle"/ligne directrice. Sans cela, vous ne faites qu'exiger une obéissance aveugle. Avec le raisonnement et les raisons, vous éduquez de manière à ce que l'affichage/la rédaction de la "règle" ne soit plus nécessaire. (car le concept sera intériorisé)

Answer 3

L'art de la programmation informatique Tome{1,2,3}

Answer 4

Basez votre style de codage sur le "C++ Coding Standard" (Sutter/Alexandrescu), et documentez uniquement les cas où vous vous en écartez. Je ne peux pas prendre au sérieux un "C++ Coding Standard" qui ne le fait pas.

Answer 5

La règle 0 devrait toujours être :

Documenter tout écart par rapport à cette norme

Certains problèmes peuvent nécessiter la non-adhésion à une norme particulière.

Ces cas doit être documentés et justifiés parce qu'ils indiquent une déviation par rapport aux idiomes attendus dans le codebase.

Ne pas les documenter peut provoquer des bugs car :

1. Un futur mainteneur peut mettre le code en conformité sans sans comprendre pourquoi il était non conforme au départ.

2. Un futur développeur peut s'attendre à ce que le code soit conforme et donc faire de la des hypothèses incorrectes sur sa signification.