CA1051: Nie deklaruj widocznych pól wystąpień
| Właściwości | Wartość |
|---|---|
| Identyfikator reguły | CA1051 |
| Tytuł | Nie deklaruj widocznych pól w wystąpieniach |
| Kategoria | Projekt |
| Poprawka powodująca niezgodność lub niezgodność | Kluczowa |
| Domyślnie włączone na platformie .NET 9 | 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
refmetody 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; }
}
}
