Jak dostosować skrót generowania pola prywatnego programu Visual Studio dla konstruktorów?

120

VS 2017 (i może starsze wersje) daje mi ten poręczny mały skrót do konstruktora do generowania private readonlypola i przypisywania go.

Zrzut ekranu:

To kończy się generowaniem prywatnego członka o nazwie, userServicea następnie przypisuje mu:

this.userService = userService;

Jest to sprzeczne ze stylem kodu, którego używam, który polega na _nadawaniu wszystkim członkom prywatnym przedrostka powodującego przypisanie, które powinno wyglądać następująco:

_userService = userService;

Jak mogę to zrobić, aby VS przestrzegał tej reguły stylu kodu dzięki skrótom generowania kodu?

c# .net visual-studio

— kspearrin
źródło

Nie ma to nic wspólnego z fragmentami kodu, tę funkcję zapewnia usługa analizy kodu. Dostępne od czasu dodania Roslyn. Wiodącym podkreśleniem jest naruszenie wytycznych .NET Framework Programming Guideline, nie ma mowy, żebyś miał zamiar namówić programistę Microsoft do zmiany tego. Jest to styl forsowany przez Resharpera, którego nie lubią, this.ponieważ to sprawia, że programista go nie kupuje, rozważ jego użycie.

— Hans Passant

@HansPassant Każdy fragment nowoczesnego kodu, jaki widziałem, wyprodukowany przez zespoły Microsoft, jest zgodny z tą _camelCasekonwencją dla prywatnych członków. Zobacz CoreFX C # Styl kodowania wytyczne , ASP.NET Rdzeń Styl kodowania , a nawet kod Rosyln sam ... ??

— kspearrin

@HansPassant Dobra wiadomość ... ktoś z sukcesem namówił programistę Microsoft, aby mógł to zmienić. Zobacz odpowiedź poniżej.

— kspearrin

Masz pomysł, jak to zrobić w programie Visual Studio dla komputerów Mac?

— Jason V

Odpowiedzi:

229

Można to również osiągnąć bezpośrednio w programie Visual Studio. Po prostu idź do Tools -> Options -> Text Editor -> C# -> Code Style -> Naming.

Najpierw musisz zdefiniować nowy styl nazewnictwa, klikając przycisk „Zarządzaj stylami nazewnictwa”:

Następnie kliknij znak +, aby zdefiniować nową regułę dla „Pola prywatnego lub wewnętrznego” korzystającą z nowego stylu nazewnictwa:

Uruchom ponownie program Visual Studio
Następnie, po zastosowaniu refaktoryzacji „Utwórz i zainicjuj pole”, zostanie ono nazwane z początkowym podkreśleniem.

— Maciek
źródło

Jestem na Visual Studio 15.8.8 i była to jedyna odpowiedź, która mi pomogła.

— Jonathan Taylor

FYI: Po tym może być konieczne ponowne uruchomienie VS.

— Jeff,

Działa dobrze w VS 2019.

— Matt Stannett

Nie wszyscy bohaterowie noszą peleryny. Świetne wyjaśnienie. Działa świetnie! Dzięki.

— datoml

W VS 2019 w wersji 16.5.4 nie jest wymagane ponowne uruchomienie

— Douglas HM

Ustawienia .editorconfig to odpowiedź kspearrin nie działa dla mnie Musiałem użyć tych (dla VS2017 w wersji 15.4.0):

[*.{cs,vb}]
dotnet_naming_rule.private_members_with_underscore.symbols  = private_fields
dotnet_naming_rule.private_members_with_underscore.style    = prefix_underscore
dotnet_naming_rule.private_members_with_underscore.severity = suggestion

dotnet_naming_symbols.private_fields.applicable_kinds           = field
dotnet_naming_symbols.private_fields.applicable_accessibilities = private

dotnet_naming_style.prefix_underscore.capitalization = camel_case
dotnet_naming_style.prefix_underscore.required_prefix = _

Mam je stąd: https://github.com/dotnet/roslyn/issues/22884#issuecomment-358776444

— michael_hook
źródło

Dziwne. Używam teraz VS 2017 15.6 i wydaje mi się, że moja pierwotna odpowiedź tam działa. Kto wie ...

— kspearrin

Zaktualizowałem do 15.6.3 i ta wersja nadal działa dla mnie. Używam wersji Community, może Ty nie?

— michael_hook

Ani nie mogę pracować, używam VS Pro 2017 w wersji 15.6.4

— Eric Schneider

po tym również: docs.microsoft.com/en-us/visualstudio/ide/ ...

— Eric Schneider

Ten zadziałał dla mnie, gdy zaakceptowana odpowiedź nie. VS Pro 15.7.5

— Licht

Można to osiągnąć, tworząc własną regułę nazewnictwa Roslyn Code Analyzer. Dodać.editorconfig rozwiązania, aby określić niestandardowe konwencje nazewnictwa.

Przeczytaj więcej o nich tutaj: https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference

Aby uzyskać pożądany efekt z pytania, zadziała:

[*.{cs,vb}]
dotnet_naming_rule.private_members_with_underscore.symbols  = private_fields
dotnet_naming_rule.private_members_with_underscore.style    = prefix_underscore
dotnet_naming_rule.private_members_with_underscore.severity = suggestion

dotnet_naming_symbols.private_fields.applicable_kinds           = field
dotnet_naming_symbols.private_fields.applicable_accessibilities = private
dotnet_naming_symbols.private_fields.required_modifiers         = readonly

dotnet_naming_style.prefix_underscore.capitalization = camel_case
dotnet_naming_style.prefix_underscore.required_prefix = _

Wynik:

— kspearrin
źródło

Wydaje mi się, że to długa droga do wykonania tego zadania. Zobacz odpowiedź @Maciek.

— Eric

To była jedyna droga powrotna, kiedy pierwotnie odpowiedziałem. Wygląda na to, że dodali teraz interfejs użytkownika.

— kspearrin

Edytowanie .editorconfig jest o wiele przyjemniejszym rozwiązaniem niż robienie tego przez interfejs użytkownika.

— gliljas

@Eric Jest na odwrót. Konieczność mówienia każdemu członkowi zespołu, aby skonfigurował swój VS w określony sposób ręcznie, jest zdecydowanie dłuższa, żmudna i podatna na błędy niż sprawdzanie .editorconfigpliku w Git i świadomość, że od tego momentu wszyscy będą automatycznie dostosowywani do swoich ustawień styl kodowania projektu.

— Daniel Liuzzi