web-dev-qa-db-fra.com

La suppression "n'est jamais utilisé" et "n'est jamais assignée à" des avertissements en C #

J'ai un fichier HTTPSystemDefinitions.cs dans le projet C # qui décrit en gros l'ancien ISAPI de Windows pour la consommation par le code managé.

Cela inclut l'ensemble complet des structures relatives à l'ISAPI qui ne sont pas toutes consommées ou qui sont consommées par le code. Lors de la compilation, tous les membres de ces structures sur le terrain provoquent un avertissement semblable à celui-ci: -

Avertissement Le champ 'UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.SetHeader' n'est jamais affecté à et aura toujours sa valeur par défaut null

ou

Avertissement Le champ 'UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.HttpStatus' n'est jamais utilisé

Peut-on les désactiver avec #pragma warning disable? Si oui, quels seraient les numéros d'erreur correspondants? Sinon, y a-t-il autre chose que je puisse faire? Gardez à l'esprit que je ne fais que faire cela pour ce fichier, il est important que je reçoive des avertissements comme ceux-ci provenant d'autres fichiers.

Éditer

Exemple struct: -

struct HTTP_FILTER_PREPROC_HEADERS
{
    //
    //  For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
    //  Header names should include the trailing ':'.  The special values
    //  'method', 'url' and 'version' can be used to retrieve the individual
    //  portions of the request line
    //

    internal GetHeaderDelegate GetHeader;
    internal SetHeaderDelegate SetHeader;
    internal AddHeaderDelegate AddHeader;

    UInt32  HttpStatus;               // New in 4.0, status for SEND_RESPONSE
    UInt32  dwReserved;               // New in 4.0
}
c#visual-studiosuppress-warnings
105
AnthonyWJones

Oui, ceux-ci peuvent être supprimés.

Normalement, je suis opposé à la suppression des avertissements, mais dans ce cas, les structures utilisées pour l'interopérabilité exigent absolument la présence de certains champs, même si vous n'avez jamais l'intention de les utiliser (ou pouvez les utiliser), aussi je pense que cela devrait être justifié. .

Normalement, pour supprimer ces deux avertissements, vous corrigeriez le code incriminé. Le premier ("... n'est jamais utilisé") est généralement une odeur de code des restes de versions antérieures du code. Peut-être le code a été supprimé, mais les champs laissés.

La seconde est généralement une odeur de code pour les champs mal utilisés. Par exemple, vous pourriez écrire de manière incorrecte la nouvelle valeur d'une propriété dans la propriété elle-même, sans jamais écrire dans le champ de sauvegarde.

Pour supprimer les avertissements pour " le champ XYZ n'est jamais utilisé ", procédez comme suit:

#pragma warning disable 0169
... field declaration
#pragma warning restore 0169

Pour supprimer les avertissements pour " le champ XYZ n'est jamais attribué à, et aura toujours sa valeur par défaut XX ", procédez comme suit:

#pragma warning disable 0649
... field declaration
#pragma warning restore 0649

Pour trouver vous-même de tels numéros d'avertissement (comment ai-je su utiliser 0169 et 0649), procédez comme suit:

  • Compilez le code normalement, cela va ajouter quelques avertissements à votre liste d'erreurs dans Visual Studio
  • Basculez vers la fenêtre de sortie et la sortie de génération et recherchez les mêmes avertissements.

  • Copiez le code d’avertissement à 4 chiffres du message correspondant, qui devrait ressembler à ceci:

    C:\Dev\VS.NET\ConsoleApplication19\ConsoleApplication19\Program.cs (10,28): avertissement CS0649: Le champ 'ConsoleApplication19.Program.dwReserved' n'est jamais attribué à et aura toujours sa valeur par défaut 0

Mise en garde : Selon le commentaire de @ Jon Hanna , peut-être que quelques avertissements sont nécessaires pour cela, pour les futurs chercheurs de cette question et réponse.

  • Tout d’abord et avant tout, supprimer un avertissement revient à avaler des pilules pour le mal de tête. Bien sûr, cela peut être la bonne chose à faire parfois, mais ce n'est pas une solution miracle. Parfois, un mal de tête est un symptôme réel que vous ne devriez pas masquer, de même que des avertissements. Il est toujours préférable d'essayer de traiter les avertissements en corrigeant leur cause, au lieu de les supprimer aveuglément de la sortie de la compilation.
  • Cela dit, si vous devez supprimer un avertissement, suivez le schéma que j’ai exposé ci-dessus. La première ligne de code, #pragma warning disable XYZK, désactive l'avertissement pour le reste de ce fichier, ou du moins jusqu'à ce qu'un #pragma warning restore XYZK est trouvé. Réduisez le nombre de lignes sur lesquelles vous désactivez ces avertissements. Le modèle ci-dessus désactive l'avertissement pour une seule ligne.
  • En outre, comme le mentionne Jon, il est judicieux de dire pourquoi vous le faites. Désactiver un avertissement est certainement une odeur de code quand il est fait sans raison, et un commentaire empêchera les futurs responsables de la maintenance de passer du temps à se demander pourquoi vous l'avez fait ou même à le supprimer et à essayer de corriger les avertissements.
189
Lasse Vågsæther Karlsen

Une autre "solution" pour résoudre ces avertissements est de rendre la struct public. Les avertissements ne sont pas émis à ce moment-là car le compilateur ne peut pas savoir si les champs sont utilisés (assignés) en dehors de l'assembly.

Cela dit, les composants "interop" ne devraient généralement pas être publics, mais plutôt internal ou private.

12
floele

J'ai eu VS pour générer le squelette d'implémentation pour System.ComponentModel.INotifyPropertyChanged et les événements ont été implémentés en tant que champs qui ont déclenché les avertissements CS0067.

Au lieu de la solution donnée dans la réponse acceptée j'ai converti les champs en propriétés et l'avertissement a dispar.

Cela a du sens puisque la syntaxe de déclaration de propriété Sugar est compilée dans un champ plus des méthodes de lecture et/ou de définition (add/remove dans mon cas) qui référencent le champ. Cela satisfait le compilateur et les avertissements ne sont pas émis:

struct HTTP_FILTER_PREPROC_HEADERS
{
    //
    //  For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
    //  Header names should include the trailing ':'.  The special values
    //  'method', 'url' and 'version' can be used to retrieve the individual
    //  portions of the request line
    //

    internal GetHeaderDelegate GetHeader {get;set;}
    internal SetHeaderDelegate SetHeader { get; set; }
    internal AddHeaderDelegate AddHeader { get; set; }

    UInt32 HttpStatus { get; set; }               // New in 4.0, status for SEND_RESPONSE
    UInt32 dwReserved { get; set; }               // New in 4.0
}
5
Pencho Ilchev

Les utilisateurs de C/C++ ont (void)var; pour supprimer les avertissements de variables inutilisées. Je viens de découvrir que vous pouvez également supprimer les avertissements de variables inutilisés en C # avec des opérateurs au niveau du bit:

        uint test1 = 12345;
        test1 |= 0; // test1 is still 12345

        bool test2 = true;
        test2 &= false; // test2 is now false

Les deux expressions ne produisent pas d'avertissements de variable inutilisés dans les compilateurs VS2010 C # 4.0 et Mono 2.10.

1
ceztko