Editorconfig w Visual Studio w niecałe 10 minut

Wprowadzenie: Dłączego EditorConfig jest ważny

Tim rozpoczyna od wprowadzenia projektu EditorConfig, tłumacząc, że ustawienia dla poszczególnych projektów są teraz łatwiejsze do wdrożenia niż kiedykolwiek. Zamiast opierać się na preferencjach osobistych zapisanych wewnątrz Visual Studio lub ustawieniach edytora, możesz teraz skonfigurować projekt, aby utrzymać spójny styl kodowania dla wszystkich współtwórców.

Tworzenie projektu

Aby zademonstrować plik EditorConfig, Tim tworzy nowy projekt Blazor Server w Visual Studio. Nazywa go BlazorDemoApp i używa domyślnej konfiguracji. Ten prosty projekt .NET służy jako poligon doświadczalny dla ustawiania i stosowania ustawień EditorConfig.

Jak wyjaśnia Tim, ten projekt nie potrzebuje skomplikówanej logiki ani funkcjonalności. To jedynie wygodny przykład do pracy z regułami stylu kodu.

Rozumienie preferencji projektu i stylów kodowania

Tutaj Tim omawia, dłączego konfiguracja na poziomie projektu jest ważna. W Visual Studio każdy użytkownik może ustawić preferencje dla takich rzeczy jak:

• Czy używać tabulatorów czy spacji

• Rozmiar wcięcia (np. 3 lub 4 spacje)

• Umiejscowienie nawiasów klamrowych {} na tej samej lub nowej linii

• Typ deklaracji przestrzeni nazw (ograniczona blokiem lub plikiem)

Te preferencje zazwyczaj są przechowywane na użytkownika w Visual Studio, a nie na projekt. Tim podkreśla, że podczas pracy w zespole, lokalne ustawienia każdego członka mogą się różnić. To może prowadzić do niespójnego formatowania kodu, niepotrzebnych różnic w systemach kontroli wersji i czasu marnowanego na ręczne dostosowywanie preferencji.

Właśnie tu pomaga format pliku EditorConfig — definiuje wspólny zestaw właściwości EditorConfig, które wszystkie edytory deweloperów mogą automatycznie respektować.

Tworzenie i otwieranie pliku EditorConfig

Następnie Tim pokazuje, jak dodać nowy plik EditorConfig do rozwiązania.

Klikając prawym przyciskiem na rozwiązanie i wybierając Dodaj → Nowy EditorConfig. Visual Studio może wyrzucić mały błąd przy pierwszym ładowaniu pliku, ale Tim wyjaśnia, że to nieszkodliwa przypadłość — wystarczy zamknąć i ponownie otworzyć plik.

Ten nowy plik zazwyczaj nazywa się .editorconfig, a Visual Studio natychmiast rozpoznaje go jako dokument konfiguracyjny. Warto zauważyć, że Visual Studio obsługuje ten plik natywnie, podobnie jak inne edytory tekstu jak Visual Studio Code czy nawet Sublime Text, poprzez wtyczki do edytora tekstu.

Tim wyjaśnia, że EditorConfig nie jest narzędziem wyłącznie Microsoftu. Jest to standard przemysłowy, który pomaga różnym edytorom zrozumieć i zastosować te same konwencje kodowania, zapewniając spójne formatowanie w różnych środowiskach.

Konfigurowanie ustawień pliku EditorConfig

Po otwarciu pliku EditorConfig, Tim wyjaśnia, że wczytuje on domyślne ustawienia z bieżącej konfiguracji Visual Studio. Jednak można je modyfikować według potrzeb.

Przechodzi do sekcji Białe znaki, pokazując, jak ustawić:

• Używaj tabulatorów zamiast spacji

• Szerokość tabulatora = 3

Są to przykłady właściwości EditorConfig, które definiują, jak powinno wyglądać formatowanie kodu. Po zapisaniu ta konfiguracja obowiązuje w całym rozwiązaniu, ale nie poza nim.

Tim zauważa, że ten plik EditorConfig można również dodać do systemów kontroli wersji (jak Git), zapewniając, że każdy deweloper, który sklonuje repozytorium, odziedziczy te same reguły. To pomaga utrzymać spójne formatowanie bez względu na to, kto pisze kod.

Praca z stylami kodu i zasadami przestrzeni nazw

Następnie Tim zagłębia się w ustawienia stylu kodu — szczególnie styl deklaracji przestrzeni nazw.

Domyślnie C# używa przestrzeni nazw ograniczonych blokiem, gdzie przestrzeń nazw jest definiowana za pomocą nawiasów klamrowych. Tim tworzy klasę w folderze Data, aby zademonstrować ten format.

Następnie zmienia ustawienie pliku EditorConfig, aby używało przestrzeni nazw ograniczonych plikiem. Gdy dodaje inną klasę, Visual Studio automatycznie stosuje zaktualizowany styl — pokazując przestrzeń nazw z średnikiem (;) zamiast nawiasów klamrowych.

To pokazuje, jak ustawienia EditorConfig mogą wpływać na domyślne szablony generowania kodu w Visual Studio, automatycznie dostosowując się do zdefiniowanych konwencji projektu.

Tim również zauważa, że funkcja oczyszczania kodu może być używana do przekształcenia istniejących plików, zapewniając zgodność całego kodu z najnowszymi regułami EditorConfig.

Ustalanie powagi i egzekwowanie zasad

W tej sekcji Tim skupia się na tym, jak kontrolować egzekwowanie reguł za pomocą poziomów powagi w pliku EditorConfig.

Każda reguła może mieć wartość jak brak, sugestia, ostrzeżenie, lub błąd. Tim ustawia powagę reguły przestrzeni nazw na błąd i natychmiast Visual Studio oznacza dowolny plik, który nie odpowiada preferowanemu formatowi w oknie Listy błędów.

Dzięki temu deweloperzy przestrzegają zdefiniowanych stylów i zapobiegają niechcianym odchyleniom w bieżącym pliku lub całym projekcie.

Podczas gdy niektóre niespójności lub błędy Visual Studio mogą się pojawić (takie jak błędne podpowiedzi), Tim zauważa, że ulegną one poprawie w czasie. Ważne jest, że zasady są stosowane konsekwentnie, dzięki czemu kod jest łatwo czytelny i jednolity.

Wiele plików EditorConfig i zakres katalogu

Tim wyjaśnia, że można mieć wiele plików EditorConfig w jednym rozwiązaniu.

Na przykład:

• Główny plik EditorConfig na poziomie rozwiązania definiuje ogólne ustawienia dla wszystkich projektów.

• Zagnieżdżony plik EditorConfig w podfolderze, jak /Data, może nadpisywać niektóre właściwości (np. konwencje nazewnictwa, szerokość zakładek, lub podział linii).

Każdy projekt EditorConfig działa hierarchicznie — co oznacza, że pliki w podkatalogach dziedziczą z katalogów nadrzędnych, chyba że są wyraźnie nadpisane.

Jeśli chcesz zdefiniować korzeń swojej konfiguracji, możesz ustawić właściwość root = true w pliku na najwyższym poziomie. To mówi edytorom, aby zaprzestały przeszukiwania katalogów nadrzędnych w poszukiwaniu kolejnych plików EditorConfig.

Ta struktura daje deweloperom szczegółową kontrolę nad zasadami formatowania na poziomie projektu, a jednocześnie pozwala na szczególne przypadki, gdzie różne formatowanie może mieć sens.

Wnioski: Spójność dzięki EditorConfig

W swoich ostatecznych uwagach Tim zachęca deweloperów do aktywnego korzystania z EditorConfig w swoich projektach .NET.

Podkreśla, że takie podejście pozwala zespołom utrzymać spójne zasady formatowania, konwencje nazewnictwa i style układu — wszystko to bez wymuszania zmian osobistych ustawień edytora. Każdy otwarty plik automatycznie podąża za zdefiniowanymi stylami ustawionymi w pliku .editorconfig projektu.

Poprzez zatwierdzanie tych plików EditorConfig do systemów kontroli wersji, zespoły zapewniają, że każdy - niezależnie od edytora czy środowiska - przestrzega tych samych reguł formatowania kodu.

Tim kończy swoje wideo podkreślając, że format pliku EditorConfig jest prosty, elastyczny i szeroko wspierany. Bez względu na to, czy używasz Visual Studio, Visual Studio Code, czy innego edytora tekstowego, znakomicie działa to, aby utrzymać spójne style kodowania i utrzymać Twój projekt czysty, profesjonalny i czytelny.