Avertissements du compilateur C / C ++: nettoyez-vous tout votre code pour les supprimer ou les laisser?

https://stackoverflow.com/questions/183788

06-07-2019
|

Question

J'ai travaillé sur de nombreux projets pour lesquels d'autres personnes m'ont donné du code à mettre à jour. Le plus souvent, je le compile et reçois environ 1 000 avertissements du compilateur. Quand je vois les avertissements du compilateur, ils me font sentir sale, alors ma première tâche consiste à nettoyer le code et à les supprimer tous. En général, je découvre une douzaine de problèmes, tels que des variables non initialisées, par exemple.

Je ne comprends pas pourquoi les gens les laissent entrer et ne disposent pas de compilations parfaitement propres sans aucun avertissement. Est-ce que je manque quelque chose? Y a-t-il une raison valable pour les laisser? Des histoires d'horreur à partager?

La solution

Je supprimerais tout avertissement. Même ceux que vous connaissez sont inoffensifs (si une telle chose existe) donneront une mauvaise impression de vous à celui qui compilera le code.

C’est l’un des "malodorants" signes que je rechercherais si je devais travailler sur le code de quelqu'un d'autre.

Si ce ne sont pas de vraies erreurs ou de futurs problèmes potentiels, ce serait un signe de négligence

Autres conseils

Nettoyez-les, même s'ils n'indiquent pas un réel problème. Sinon, si un message vous avertit qu'un réel problème apparaît, vous ne le verrez pas malgré tous les bruits.

Sur mon travail, le paramétrage du compilateur pour traiter les avertissements comme des erreurs est activé. Donc, pas d’avertissement, sinon ça ne compilera pas:)

Je conviens qu'il est préférable d'éliminer tous les avertissements. Si vous recevez des milliers d'avertissements, vous devez hiérarchiser vos correctifs.

Commencez par régler votre compilateur sur le niveau d’avertissement le plus bas. Ces avertissements devraient être les plus importants. Lorsque ces problèmes sont résolus, augmentez votre niveau d’avertissement et répétez-le jusqu’à atteindre le niveau d’avertissement le plus élevé. Définissez ensuite les options de compilation de sorte que les avertissements soient traités comme des erreurs.

Si vous trouvez un avertissement que vous pensez pouvoir ignorer, faites des recherches pour vérifier votre théorie. Ensuite seulement, désactivez-le et seulement de la manière la plus minimale possible. La plupart des compilateurs ont des directives #pragma pouvant désactiver / activer les avertissements pour seulement une partie d'un fichier. Voici un exemple Visual C ++:

typedef struct _X * X; // from external header, not 64-bit portable

#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )

Notez que cela ne désactive l'avertissement que pour une seule ligne de code. L’utilisation de cette méthode vous permet également d’effectuer ultérieurement une simple recherche textuelle dans votre code pour y apporter des modifications.

Sinon, vous pouvez généralement désactiver un avertissement particulier pour un fichier unique ou pour tous les fichiers. IMHO cela est dangereux et ne devrait être qu'un dernier recours.

Nettoyez-les si possible . Sur une base de code multi-plateforme / multi-compilateur (j’ai travaillé sur une base compilée sur 7 systèmes d’exploitation différents avec 6 compilateurs différents), ce n’est pas toujours possible. J'ai déjà vu des cas où le compilateur est faux (HP-UX aCC sur Itanium, je vous regarde), mais il est vrai que c'est rare. Comme d'autres personnes le notent, vous pouvez désactiver l'avertissement dans une telle situation.

Plusieurs fois, un avertissement dans cette version du compilateur peut devenir une erreur dans la prochaine version (toute personne effectuant une mise à niveau de gcc 3.x à 4.x devrait le connaître), alors nettoyez-le maintenant.

Certains compilateurs émettront des avertissements très utiles qui deviendront des problèmes dans certaines circonstances - Visual C ++ 2005 et 2008 peuvent vous avertir des problèmes 64 bits, ce qui est un énorme avantage de nos jours. Si vous envisagez de migrer vers la version 64 bits, le simple nettoyage de ce type d'avertissements réduira considérablement la durée de votre port.

Il y a des cas où je laisse des avertissements dans le code, ou dans lesquels il est impossible de les nettoyer (même si je supprime ceux que je peux). Par exemple:

Si vous travaillez sur quelque chose et que vous savez qu'il nécessite plus de travail / d'attention, laissez un avertissement en place pour indiquer que cela peut être approprié
Si vous compilez C ++ avec / clr, il y a plusieurs avertissements sur les causes de la génération de code natif; il peut être fastidieux de supprimer tous ces avertissements lorsque la base de code ne peut pas être modifiée de façon fonctionnelle
Suppression des avertissements lorsque vous ne comprenez pas en quoi consiste le correctif. Je l'ai déjà fait plusieurs fois avec un avertissement PC-Lint et j'ai fini par introduire des bogues. Si vous ne savez pas quel est l'effet exact de la modification (par exemple: les conversions en style C pour éliminer les avertissements), ne le faites pas. Comprendre l'avertissement ou laisser le code seul est mon conseil.

Quoi qu’il en soit, ce sont des cas qui me viennent à l’esprit où laisser des avertissements peut-être approprié.

Le pire, c’est que lorsque vous écrivez un nouveau code, il est difficile de savoir si vous avez introduit par inadvertance plus d’avertissements, car il en existe tellement que vous les ignorez quand même.

Le problème avec tous les nettoyer, c'est que cela prend du temps que vous pouvez ou ne pas avoir. Mais oui, en général, vous devriez en nettoyer autant que vous le pouvez.

Laisser des avertissements dans votre code, car vous n'avez pas le temps de les corriger, c'est comme ne pas vous brosser les dents, car vous n'avez pas assez de temps le matin. C’est une question fondamentale d’hygiène du code.

Nettoyez toujours vos avertissements. Si vous connaissez un cas spécifique dans lequel vous savez que l'avertissement est correct, supprimez-le uniquement pour cette instance.

Bien que certains avertissements puissent être bénins, la plupart signifient un réel problème avec le code.

Si vous ne nettoyez pas tous vos avertissements, la liste des avertissements continuera de s'allonger et les vrais problèmes disparaîtront dans un océan de bruits d'avertissement.

L'une des caractéristiques d'un très bon programmeur est qu'un mauvais code leur donne mal à l'aise.

Je m'efforce de faire en sorte que tout mon code soit non seulement propre au compilateur, mais également propre dans mon environnement de développement IDE à un niveau assez difficile. Je dois parfois supprimer une instance d'avertissement si je connais mieux que l'outil, mais au moins, cela sert également de documentation.

J'active toujours tous les avertissements, puis je règle mon projet pour qu'il cesse de construire s'il y a des avertissements.

S'il y a des avertissements, vous devez vérifier chacun d'eux pour vous assurer qu'il n'y a pas de problème. Faire cela encore et encore est une perte de temps. Si vous ne le faites pas, cela entraînera des erreurs dans votre code.

Il existe des moyens de supprimer un avertissement (par exemple, #pragma argsused).

Laissez le compilateur faire le travail.

J'ai travaillé avec un certain nombre de systèmes intégrés où les avertissements entraîneraient une instabilité, un crash ou une corruption de la mémoire. À moins que vous ne sachiez que l'avertissement est inoffensif, vous devez en tenir compte.

Les avertissements sont et devraient être traités comme des bugs. Si vous ne pouvez pas coder suffisamment bien pour vous débarrasser de vos avertissements, vous ne devriez probablement pas coder. Dans mon groupe, nous avons pris la décision de forcer tous les avertissements à des erreurs. Cela met fin à cette discussion et, à mon humble avis, améliore la qualité du code.

Je n'aime pas les avertissements. Je les enlève autant que possible.
Parfois, quand je suis sous pression pour finir le travail, j'en quitte certains. Je les laisse rarement cependant. Je me sens comme toi, sale s’il en reste.

La base de code sur laquelle je travaille a plus de 4000 avertissements. Certains d'entre eux sont des problèmes légitimes. On ne nous donne jamais le temps d'aller les réparer, ni de refactoriser d'autres choses cassées ... En partie, c'est parce que le code est si ancien qu'il est antérieur à la norme C ++. Nous ne pouvons compiler que dans VC ++ 6.

Nettoyez toujours tous les avertissements ou supprimez-les explicitement si nécessaire. Les réglages par défaut pour les avertissements devraient être les plus élevés possibles lors de la compilation (niveau 4 sur VS par exemple).

Mon patron qui a créé le code que je gère maintenant. Il utilise les indicateurs du compilateur pour masquer ses avertissements de dépréciation.

Quand j'ai le temps, je passe et nettoie ce que je peux.

J'essaie de compiler du code avec un niveau assez élevé d'avertissements et de les nettoyer, à l'exception de "comparaison signée / non signée". avertissements, que je suis sûr que je devrais corriger mais ne peut jamais être dérangé.

Version abrégée: j'utilise " -Wextra -Wno-sign-compare " et se débarrasser de tous les messages.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow