Lignes directrices pour améliorer votre code

Question

Quelles directives suivez-vous pour améliorer la qualité générale de votre code ?De nombreuses personnes ont des règles sur la façon d'écrire du code C++ qui (soi-disant) rendent plus difficile la commission d'erreurs.j'ai vu des gens insister que chaque if L'instruction est suivie d'un bloc d'accolade ({...}).

Je m'intéresse aux directives que les autres suivent et aux raisons qui les sous-tendent.Je suis également intéressé par les lignes directrices que vous considérez comme de la foutaise, mais qui sont largement répandues.Quelqu'un peut-il en suggérer quelques-uns ?

Pour lancer le bal, j'en mentionnerai quelques-uns pour commencer :

• Utilisez toujours un appareil dentaire après chaque if / else déclaration (mentionnée ci-dessus).La raison derrière cela est qu'il n'est pas toujours facile de savoir si une seule instruction est en réalité une seule instruction, ou une macro de préprocesseur qui s'étend à plusieurs instructions, donc ce code serait cassé :

    // top of file:
    #define statement doSomething(); doSomethingElse

    // in implementation:
    if (somecondition)
        doSomething();

mais si vous utilisez des accolades, cela fonctionnera comme prévu.

• Utilisez les macros du préprocesseur UNIQUEMENT pour la compilation conditionnelle.les macros de préprocesseur peuvent provoquer toutes sortes d'enfers, car elles n'autorisent pas les règles de portée C++.Je me suis échoué plusieurs fois à cause de macros de préprocesseur avec des noms communs dans les fichiers d'en-tête.Si vous ne faites pas attention, vous pouvez causer toutes sortes de dégâts !

Maintenant à vous.

Answer 1

Quelques-uns de mes favoris personnels :

Efforcez-vous d'écrire du code qui est const correct.Vous ferez appel au compilateur pour vous aider à éliminer les bogues faciles à corriger mais parfois douloureux.Votre code racontera également une histoire de ce que vous aviez en tête au moment où vous l'avez écrit – ce qui sera précieux pour les nouveaux arrivants ou les responsables une fois que vous serez parti.

Sortez du secteur de la gestion de la mémoire.Apprenez à utiliser les pointeurs intelligents : std::auto_ptr, std::tr1::shared_ptr (ou boost::shared_ptr) et boost::scoped_ptr.Apprenez les différences entre eux et quand en utiliser un plutôt qu'un autre.un autre.

Vous allez probablement utiliser la bibliothèque de modèles standard.Lis le Livre de Josuttis.Ne vous arrêtez pas après les premiers chapitres sur les conteneurs en pensant que vous connaissez la STL.Passez aux bonnes choses :algorithmes et objets fonction.

Answer 2

1. Supprimez le code inutile.

C'est tout.

Answer 3

• Utilisez et appliquez un style de codage et des directives communs. Raisonnement: Chaque développeur de l'équipe ou de l'entreprise est capable de lire le code sans distractions pouvant survenir en raison de différents styles d'accolades ou similaires.
• Effectuez régulièrement une reconstruction complète de l'ensemble de votre base de sources (c'est-à-direeffectuez des builds quotidiens ou des builds après chaque enregistrement) et signalez toute erreur ! Raisonnement: La source est presque toujours dans un état utilisable et les problèmes sont détectés peu de temps après leur « mise en œuvre », là où la résolution des problèmes est bon marché.

Answer 4

Activez tous les avertissements que vous pouvez afficher dans votre compilateur (gcc : -Wall est un bon début mais n'inclut pas tout, alors vérifiez la documentation), et faites-leur des erreurs afin que vous deviez les corriger (gcc : -Werror).

Answer 5

Le guide de style de Google, mentionné dans l'une de ces réponses, est assez solide.Il y a des choses inutiles dedans, mais c'est plus bon que mauvais.

Sutter et Alexandrescu ont écrit un livre intéressant sur ce sujet, intitulé Normes de codage C++.

Voici quelques conseils généraux de mon petit vieux :

1. Votre style d’indentation et de crochetage est tous deux faux.Tout le monde aussi.Suivez donc les normes du projet pour cela.Ravalez votre fierté et configurez votre éditeur pour que tout soit aussi cohérent que possible avec le reste de la base de code.C'est vraiment très ennuyeux de devoir lire du code dont l'indentation est incohérente.Cela dit, le crochet et l'indentation n'ont rien à voir avec "l'amélioration de votre code". Il s'agit davantage d'améliorer votre capacité à travailler avec les autres.

2. Commentez bien.C'est extrêmement subjectif, mais en général, il est toujours bon d'écrire des commentaires sur pourquoi le code fonctionne comme il le fait, plutôt que d'expliquer ce qu'il fait.Bien sûr, pour du code complexe, il est également utile aux programmeurs qui ne sont pas familiers avec l'algorithme ou le code d'avoir une idée de quoi ça marche aussi.Les liens vers les descriptions des algorithmes utilisés sont les bienvenus.

3. Exprimez la logique de la manière la plus simple possible.Ironiquement, des suggestions telles que "mettre les constantes sur le côté gauche des comparaisons" ont mal tourné ici, je pense.Ils sont très populaires, mais pour les anglophones, ils interrompent souvent le flux logique du programme pour ceux qui lisent.Si vous ne pouvez pas faire confiance à vous-même (ou à votre compilateur) pour écrire correctement les comparaisons d'égalité, alors utilisez certainement des astuces comme celle-ci.Mais vous sacrifiez la clarté en le faisant.Entrent également dans cette catégorie des choses comme..."Ma logique a-t-elle 3 niveaux d'indentation ?Cela pourrait-il être plus simple ?" et intégrer un code similaire dans des fonctions.Peut-être même diviser les fonctions.Il faut de l'expérience pour écrire du code qui exprime avec élégance la logique sous-jacente, mais cela vaut la peine d'y travailler.

C’était assez général.Pour des conseils spécifiques, je ne peux pas faire un bien meilleur travail que Sutter et Alexandrescu.

Answer 6

Dans les instructions if, placez la constante à gauche, c'est-à-dire

if( 12 == var )

pas

if( var == 12 )

Parce que si vous manquez de taper un '=' alors cela devient une affectation.Dans la version supérieure, le compilateur dit que ce n'est pas possible, dans cette dernière, il s'exécute et le if est toujours vrai.

J'utilise des accolades pour les if chaque fois qu'ils ne sont pas sur la même ligne.

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

Les accolades ouvertes et fermées ont toujours leurs propres lignes.Mais c’est bien sûr une convention personnelle.

Answer 7

Ne commentez que lorsqu'il est uniquement nécessaire d'expliquer ce que fait le code, là où la lecture du code ne pourrait pas vous dire la même chose.

Ne commentez pas le code que vous n'utilisez plus.Si vous souhaitez récupérer l'ancien code, utilisez votre système de contrôle de code source.Commenter le code ne fait que rendre les choses compliquées et faire disparaître vos commentaires qui sont réellement importants dans le désordre d'arrière-plan du code commenté.

Answer 8

1. Utilisez une mise en forme cohérente.
2. Lorsque vous travaillez sur du code existant, utilisez le style de formatage existant, en particulier.style d'accolade.
3. Obtenez une copie du livre de Scott Meyer Effective C++
4. Obtenez une copie du livre Code Complete de Steve MConnell.

Answer 9

Il y a aussi un joli Guide de style C++ utilisé en interne par Google, qui reprend la plupart des règles mentionnées ici.

Answer 10

Commencez à écrire beaucoup de commentaires, mais profitez-en pour refactoriser le code afin qu'il soit explicite.

c'est à dire:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

Cela aurait dû être quelque chose comme

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

Answer 11

• Utilisez des onglets pour les indentations, mais alignez les données avec les espaces, cela signifie que les gens peuvent décider de la quantité à induire en modifiant la taille de l'onglet, mais aussi que les choses restent alignées (par exemple, vous voudrez peut-être tout le '=' dans une ligne verticale lorsque vous attribuez des valeurs à un struct)

• Utilisez toujours des constantes ou des fonctions en ligne au lieu de macros lorsque cela est possible

• N'utilisez jamais « using » dans les fichiers d'en-tête, car tout ce qui inclut ce heafer sera également affecté, même si la personne qui inclut votre en-tête ne veut pas que tout std (par exemple) soit dans son espace de noms global.

• Si quelque chose fait plus de 80 colonnes environ, divisez-le en plusieurs lignes, par exemple

  if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
     BigVaribleIsValid(SomeVeryLongVaribleName))
  {
      DoSomething();
  }
  

• Surcharger uniquement les opérateurs pour les faire faire ce que l'utilisateur attend, par exemple, surcharger les opérateurs + et - pour un 2dVector est très bien.

• Commentez toujours votre code, même si c'est juste pour dire ce que fait le bloc suivant (par exemple "supprimer toutes les textures qui ne sont pas nécessaires pour ce niveau").Quelqu'un devra peut-être travailler avec lui plus tard, peut-être après votre départ, et il ne veut pas trouver des milliers de lignes de code sans commentaires pour indiquer ce qui fait quoi.

Answer 12

1. configurez la convention de codage et faites en sorte que toutes les personnes impliquées suivent la convention (vous ne voudriez pas lire du code qui vous oblige à déterminer où se trouve la prochaine instruction/expression car elle n'est pas correctement indentée)
2. refactoriser constamment votre code (obtenez une copie de Refactoring, de Martin Fowler, les avantages et les inconvénients sont détaillés dans le livre)
3. écrire du code faiblement couplé (évitez d'écrire des commentaires en écrivant du code explicite, le code faiblement couplé a tendance à être plus facile à gérer/à adapter au changement)
4. si possible, testez unitairement votre code (ou si vous êtes assez macho, TDD.)
5. sortir tôt, sortir souvent
6. éviter une optimisation prématurée (le profilage aide à l'optimisation)

Answer 13

Dans le même esprit, vous pourriez trouver quelques suggestions utiles ici : Comment faire en sorte qu'un mauvais code paraisse faux ?Quels modèles utilisez-vous pour éviter les erreurs sémantiques ?

Answer 14

Lorsque vous le pouvez, utilisez le pré-incrément au lieu du post-incrément.

Answer 15

J'utilise PC-Lint sur mes projets C++ et j'aime particulièrement la façon dont il fait référence aux publications existantes telles que les directives MISRA ou "Effective C++" et "More Effective C++" de Scott Meyers.Même si vous envisagez d'écrire des justifications très détaillées pour chaque règle vérifiée par votre outil d'analyse statique, c'est une bonne idée de pointer vers des publications établies auxquelles votre utilisateur fait confiance.

Answer 16

Voici le conseil le plus important que m'a donné un gourou du C++, et il m'a aidé à quelques occasions critiques à trouver des bugs dans mon code :

• Utilisez les méthodes const lorsqu'une méthode est pas supposé pour modifier l'objet.
• Utilisez des références const et des pointeurs dans les paramètres lorsque l'objet est pas supposé pour modifier l'objet.

Avec ces 2 règles, le compilateur vous indiquera gratuitement où dans votre code la logique est erronée !

Answer 17

Aussi, pour quelques bonnes techniques que vous pourriez suivre Le blog de Google "Tests sur les toilettes".

Answer 18

Regarde-le six mois plus tard

Answer 19

assurez-vous de bien mettre en retrait

Answer 20

Hmm – j'aurais probablement dû être un peu plus précis.

Je ne cherche pas tellement de conseils pour moi-même - j'écris un outil d'analyse de code statique (les offres commerciales actuelles ne sont tout simplement pas assez bonnes pour ce que je veux), et je cherche des idées de plugins pour mettre en évidence les possibilités erreurs dans le code.

Plusieurs personnes ont mentionné des choses comme l'exactitude de la const et l'utilisation de pointeurs intelligents - c'est le genre de réflexion que je peux vérifier.Vérifier l'indentation et les commentaires est un peu plus difficile à faire (du point de vue de la programmation en tout cas).

Answer 21

Les pointeurs intelligents permettent d’indiquer très clairement la propriété.Si vous êtes une classe ou une fonction :

• si vous obtenez un pointeur brut, tu ne possèdes rien.Vous êtes autorisé à utiliser la pointe, gracieuseté de votre appelant, qui garantit que la pointe restera en vie plus longtemps que vous.
• si vous obtenez un faible_ptr, vous n'êtes pas propriétaire de la pointe, et en plus la pointe peut disparaître à tout moment.
• si vous obtenez un partagé_ptr, vous possédez l'objet avec d'autres, vous n'avez donc pas à vous inquiéter.Moins de stress, mais aussi moins de contrôle.
• si vous obtenez un auto_ptr, vous êtes l'unique propriétaire de l'objet.C'est à toi, tu es le roi.Vous avez le pouvoir de détruire cet objet ou de le donner à quelqu'un d'autre (perdant ainsi la propriété).

Je trouve les arguments en faveur de auto_ptr particulièrement solides :dans une conception, si je vois un auto_ptr, je sais immédiatement que cet objet va "errer" d'une partie du système à l'autre.

C'est du moins la logique que j'utilise sur mon projet favori.Je ne sais pas combien de variations il peut y avoir sur le sujet, mais jusqu'à présent, cet ensemble de règles m'a bien servi.