Lors de la révision du code C / C, nous trouvons assez souvent des variables qui ne sont jamais utilisées. Ces variables inutilisées se produisent pour diverses raisons. Dans cet article, nous examinons certaines des causes les plus courantes pourquoi les variables inutilisées se produisent dans le code C / C. Nous passons en revue comment faire avertir le compilateur des variables inutilisées, et comment supprimer les avertissements pour des variables inutilisées spécifiques.

Pourquoi les variables ne sont pas utilisées

Il existe de nombreuses raisons pour lesquelles les variables inutilisées peuvent rester dans une base de code. Ceux-ci incluent:

1. bogues et erreurs : La raison la plus évidente d'une variable inutilisée est le code défectueux. Soit la variable n'est vraiment pas nécessaire du tout et peut être supprimée, soit la variable est nécessaire, mais nous avons oublié de l'utiliser à certains points critiques.

2. refactoring: Au fur et à mesure que le logiciel est écrit et réécrit, des sections de code entières peuvent être supprimées. Les variables qui étaient autrefois essentielles pour le code, telles que les résultats des calculs auxiliaires, peuvent alors être laissées derrière, inutilisées.

3. Future-Infirmeing: Les variables inutilisées pourraient non seulement se produire comme un héritage de code passé mais aussi comme héritage du code futur. Vous pouvez déclarer des variables en prévision du code qui reste à écrire.

4. Compilation conditionnelle: Les variables peuvent rester inutilisées en fonction de la phase du préprocesseur. Un exemple standard est une variable qui n'est définie qu'à des fins de débogage. Votre code peut contenir quelque chose du formulaire
   

const auto value = compute_some_value();
const auto value_for_comparison_only = compute_same_value_differently();
assert( value == value_for_comparison_only );

Si vous compilez avec -dndebug, alors le compilateur peut vous avertir que Value_For_Comparison_Only n'est jamais utilisé: En effet, l'instruction ASSERT a été remplacée par… rien.

Comment détecter les variables inutilisées

Différents compilateurs et paramètres de niveau d'avertissement peuvent influencer si une variable est signalée comme inutilisée pendant le processus de compilation.

Par exemple, GCC et Clang présentent le drapeau à variable -wunused, qui déclenche des avertissements des variables inutilisées. Le drapeau est déjà impliqué par l'option d'avertissement -Wall, et il peut être désactivé via -wno-unlé-variable.

Ma recommandation est de toujours compiler avec -Wall, puis de désactiver sélectivement les avertissements comme autorisés. Tous les instances de variables inutilisées.

Comment ne pas détecter les variables inutilisées: attributs

Bien que nous devrions toujours compiler avec autant d'avertissements activés que possible, il y a des circonstances où nous voulons désactiver sélectivement les avertissements sur des variables inutilisées particulières. Une façon populaire de le faire est un casting à vide:

Object unused_object;
(void)unused_object;

Le casting en vide compte comme une utilisation (pro forma) de la variable, donc aucun avertissement ne sera émis.

Bien que cela supprime les avertissements selon lesquels UNUSED_OBJECT est inutilisé, tout comme prévu, il existe des moyens d'améliorer cela. Nous aimerions avoir une sémantique explicite que ce cast vide signifie un objet inutilisé. Une manière commune est en définissant une macro:

#define UNUSED(x) (void)(x);
// ...
Object unused_object;
UNUSED(unused_object);

Un avantage est que nous communiquons maintenant explicitement l'intention (ou son absence) de cette variable. De plus, si nous décidons de purger le code des variables inutilisées, alors les rechercher est beaucoup plus facile.

Avant les macros, nous avons des attributs variables: natifs de la langue C ou comme extension de langue fournie par les compilateurs C / C. Par exemple, Clang et GCC permettent l'attribut variable __attribute __ ((inutilisé)). C 17 prend en charge l'attribut [[peut-être_unUsed]]:

Object unused_object2 __attribute__((unused)) = x;  // should be placed after declaration
[[maybe_unused]] Object unused_object1 = x;         // must be placed before declaration

Ces attributs communiquent au compilateur (et pour nous) que ces variables pourraient être inutilisées et que nous sommes très bien avec cela.

Historiquement, les attributs GCC sont apparus en premier, étant des extensions de langage spécifiques au compilateur en c et c. À partir de C 17, les attributs font partie de la norme linguistique. Cependant, non seulement l'orthographe est différente, mais la norme et les extensions de GCC ne conviennent pas où placer l'attribut.

L'attribut [[peut-être_unus]] trouvera la plupart de ses applications avec une compilation conditionnelle. Par exemple, il s'agit d'un attribut naturel pour les variables de débogage uniquement. Pour des raisons purement esthétiques, je préfère personnellement définir une macro #define peut-être_unused [[peut-être_unused]].

Un avantage de __attribute __ ((inutilisé)) est qu'il vous avertira en fait si la variable est jamais utilisée dans le code. Ce n'est pas peut-être inutilisé mais ne soit certainement pas utilisé, et l'utilisation de la variable produira désormais un avertissement.

Garder des choses inutiles

Apparemment, les variables inutilisées sont suffisamment fréquentes et suffisamment importantes pour justifier leurs propres extensions linguistiques.

Par comparaison, commentant la variable inutilisée une bonne stratégie? Pas toujours! Il y a des raisons pour lesquelles vous garderiez une variable inutilisée tout au long du code de développement et de la phase de débogage. Supposons que la variable ait été utilisée dans une version passée du code, peut-être que vous n'avez même pas encore décidé si l'ancien code devait être mis de côté ou réintégré; Signification: vous ne savez pas si vous avez besoin de la variable inutilisée.

Il pourrait être utile pour que le débogage de conserver le code comme:

auto unused_variable __attribute__((unused)) = complicated_calculation( arg1, arg2, arg3 );

Même si le résultat du calcul compliqué n'est jamais utilisé, le garder constitue un autre point d'échec… et c'est exactement ce que vous voulez pendant le débogage. Même s'il n'est pas destiné à le débogage, faire en sorte que le programme initialise cette variable sera utile si vous décidez jamais que vous en avez besoin (encore).

J'espère que cette publication sur les variables inutilisées vous a été utile.