Suppression des avertissements "is never used" et "is never assigned to" en C#

Question

J'ai un fichier HTTPSystemDefinitions.cs dans un projet C# qui décrit essentiellement l'ancienne ISAPI de Windows pour la consommation par le code géré.

Cela comprend l'ensemble des structures pertinentes pour l'ISAPI, qui ne sont pas toutes consommées par le code. Lors de la compilation, tous les champs de ces structures provoquent un avertissement du type suivant:-

Attention Le champ 'UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.SetHeader' n'a jamais été affecté et aura toujours sa valeur par défaut, qui est nulle.

ou

Attention 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 dois faire cela que pour ce fichier, il est important que je ne voie pas d'avertissements de ce type provenant d'autres fichiers.

Editar

Exemple de structure:-

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
}

Answer 1

Oui, ils peuvent être supprimés.

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

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

Le second est généralement un code-smell pour les champs mal utilisés. Par exemple, vous pouvez é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 d'appui.

---

Pour supprimer les avertissements pour " Le champ XYZ n'est jamais utilisé ", vous faites ceci :

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

Pour supprimer les avertissements pour " Le champ XYZ n'est jamais affecté, et aura toujours sa valeur par défaut XX ", vous faites ceci :

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

Pour trouver vous-même ces numéros d'avertissement (par exemple, comment ai-je su qu'il fallait utiliser le 0169 et le 0649), vous devez procéder comme suit :

• Compilez le code normalement, cela ajoutera quelques avertissements à votre liste d'erreurs dans Visual Studio.
• Passez à la fenêtre Output, et à la sortie Build, et recherchez les mêmes avertissements.

• Copiez le code d'avertissement à 4 chiffres du message concerné, qui doit ressembler à ceci :

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

---

Caveat : Conformément au commentaire de @Jon Hanna Peut-être que quelques avertissements s'imposent, pour les futurs utilisateurs de cette question et de cette réponse.

• D'abord et avant tout, l'acte de supprimer une alerte s'apparente à avaler des pilules contre le mal de tête. Bien sûr, c'est parfois la bonne chose à faire, mais ce n'est pas une solution universelle. Parfois, un mal de tête est un symptôme réel qu'il ne faut pas masquer, de même pour les avertissements. Il est toujours préférable d'essayer de traiter les avertissements en corrigeant leur cause, plutôt que de les supprimer aveuglément du résultat 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 du fichier ou au moins jusqu'à ce qu'un #pragma warning restore XYZK est trouvé. Réduisez au minimum le nombre de lignes sur lesquelles vous désactivez ces avertissements. Le modèle ci-dessus désactive l'avertissement pour une seule ligne.
• De plus, comme le mentionne Jon, il est bon d'expliquer pourquoi vous faites cela. Désactiver un avertissement est définitivement une odeur de code quand c'est fait sans raison, et un commentaire évitera aux futurs mainteneurs de passer du temps à se demander pourquoi vous l'avez fait, ou même à le supprimer et à essayer de corriger les avertissements.

Answer 2

Une autre "solution" pour corriger ces avertissements est de rendre la structure public . Les avertissements ne sont alors pas émis car le compilateur ne peut pas savoir si les champs sont utilisés (assignés) en dehors de l'assemblage.

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

Answer 3

J'ai obtenu de VS qu'il génère le squelette de l'implémentation pour System.ComponentModel.INotifyPropertyChanged et les événements ont été implémentés comme des champs qui ont déclenché les avertissements CS0067.

Comme alternative à la solution donnée dans la réponse acceptée J'ai converti les champs en propriétés et l'avertissement a disparu. .

C'est logique puisque les déclarations de propriétés de la syntaxe sugar sont compilées en un champ et des méthodes getter et/ou setter (add/remove dans mon cas) qui font référence au 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
}

Answer 4

Les utilisateurs de C/C++ ont (void)var; pour supprimer les avertissements relatifs aux variables inutilisées. Je viens de découvrir que l'on peut également supprimer les avertissements relatifs aux variables inutilisées en C# avec les opérateurs bitwise :

        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 relatifs aux variables inutilisées dans les compilateurs VS2010 C# 4.0 et Mono 2.10.