CA1051: Nie deklaruj widocznych pól wystąpień

  • Artykuł
Właściwości Wartość
Identyfikator reguły CA1051
Stanowisko Nie deklaruj widocznych pól w wystąpieniach
Kategoria Projekt
Poprawka powodująca niezgodność lub niezgodność Kluczowa
Domyślnie włączone na platformie .NET 8 Nie.

Przyczyna

Typ ma pole wystąpienia innego niż prywatne.

Domyślnie ta reguła analizuje tylko typy widoczne zewnętrznie, ale można to skonfigurować.

Opis reguły

Głównym zastosowaniem pola powinno być to, co szczegółowo opisuje implementacja. Pola powinny być private lub internal powinny być uwidocznione za pomocą właściwości. Dostęp do właściwości jest tak prosty, jak w przypadku uzyskiwania dostępu do pola, a kod w metodzie dostępu do właściwości może ulec zmianie, ponieważ funkcje typu rozszerzają się bez wprowadzania zmian powodujących niezgodność.

Właściwości, które po prostu zwracają wartość pola prywatnego lub wewnętrznego, są zoptymalizowane pod kątem wykonywania na równi z dostępem do pola; wydajność przy użyciu pól widocznych zewnętrznie zamiast właściwości jest minimalna. Widoczne zewnętrznie odnosi się do publicpoziomów ułatwień dostępu , protectedi protected internal (Public, Protectedi Protected Friend w Visual Basic).

Ponadto pola publiczne nie mogą być chronione przez żądania linków. (Wymagania dotyczące linków nie mają zastosowania do aplikacji platformy .NET Core).

Jak naprawić naruszenia

Aby naprawić naruszenie tej reguły, wprowadź pole private lub internal uwidocznij je przy użyciu właściwości widocznej zewnętrznie.

Kiedy pomijać ostrzeżenia

Pomiń to ostrzeżenie tylko wtedy, gdy masz pewność, że konsumenci potrzebują bezpośredniego dostępu do pola. W przypadku większości aplikacji uwidocznione pola nie zapewniają korzyści z wydajności ani konserwacji w odniesieniu do właściwości.

Konsumenci mogą potrzebować dostępu do pól w następujących sytuacjach:

  • W kontrolkach zawartości ASP.NET Web Forms.
  • Gdy platforma docelowa używa ref metody do modyfikowania pól, takich jak struktury model-view-viewmodel (MVVM) dla platform WPF i UWP.

Pomijanie ostrzeżenia

Jeśli chcesz po prostu pominąć pojedyncze naruszenie, dodaj dyrektywy preprocesora do pliku źródłowego, aby wyłączyć, a następnie ponownie włączyć regułę.

#pragma warning disable CA1051
// The code that's violating the rule is on this line.
#pragma warning restore CA1051

Aby wyłączyć regułę dla pliku, folderu lub projektu, ustaw jego ważność na none w pliku konfiguracji.

[*.{cs,vb}]
dotnet_diagnostic.CA1051.severity = none

Aby uzyskać więcej informacji, zobacz Jak pominąć ostrzeżenia dotyczące analizy kodu.

Dołączanie lub wykluczanie interfejsów API

Użyj poniższych opcji, aby skonfigurować, które części bazy kodu mają być uruchamiane w tej regule.

Możesz skonfigurować te opcje tylko dla tej reguły, dla wszystkich reguł, do których ma ona zastosowanie, lub dla wszystkich reguł w tej kategorii (Projekt), do których ma ona zastosowanie. Aby uzyskać więcej informacji, zobacz Opcje konfiguracji reguły jakości kodu.

Uwzględnij określone powierzchnie interfejsu API

Możesz skonfigurować, na których częściach bazy kodu ma być uruchamiana ta reguła, na podstawie ich ułatwień dostępu. Aby na przykład określić, że reguła powinna być uruchamiana tylko na powierzchni niepublicznego interfejsu API, dodaj następującą parę klucz-wartość do pliku editorconfig w projekcie:

dotnet_code_quality.CAXXXX.api_surface = private, internal

Wykluczanie struktur

Możesz wykluczyć struct pola (Structure w Visual Basic) z analizowanych.

dotnet_code_quality.ca1051.exclude_structs = true

Przykład

W poniższym przykładzie przedstawiono typ (BadPublicInstanceFields), który narusza tę regułę. GoodPublicInstanceFields wyświetla poprawiony kod.

public class BadPublicInstanceFields
{
    // Violates rule DoNotDeclareVisibleInstanceFields.
    public int instanceData = 32;
}

public class GoodPublicInstanceFields
{
    private int instanceData = 32;

    public int InstanceData
    {
        get { return instanceData; }
        set { instanceData = value; }
    }
}

Zobacz też