C# via R#, czyli 11 powodów do używania Resharpera (part 3)

Jesteśmy świadkami wydarzenia oczekiwanego na całym świecie, porównywalnego (no, trochę na wyrost:) ) z premierą VS2008, czyli Resharper 4.0! Z tej niezwykłej okazji zapraszam na trzecią, prawdopodobnie ostatnią i momentami odrobinę naciąganą, odsłonę cyklu “11 powodów do używania Resharpera”. Dla przypomnienia: część 1, część 2. No to jadziem z dziadziem:

1) Uruchamianie testów jednostkowych

Niedawno miałem niewątpliwie szczęśliwą okazję wypróbować w żywym projekcie R# współgrającego z testami jednostkowymi (nie stricte TDD, ale jednak testy). I zaskoczenia nie ma… sprawdza się wyśmienicie! Proponowane przeze mnie rozwiązanie dla wersji Express (tutaj) po prostu odpada w przedbiegach. Cóż zatem magicy z Jetbrains mają nam do zaoferowania? Po pierwsze: zintegrowany “test runner” w bardzo przystępny sposób ukazujący efekt wykonania wszystkich testów:

Po drugie: polecenia w try-mi-ga uruchamiające żądane testy. Do wyboru mamy “run all solution” (proponuję [ctrl]+r+a) wykonujący wszystkie zawarte w rozwiązaniu testy, jak i “run context” ([ctrl]+r+t) inteligentnie wybierający testy do odpalenia. Jeżeli kursor znajduje się w metodzie testującej – jedynie owa metoda będzie celem działań R# jeżeli kursor mamy poza ciałem metody, ale w klasie testowej – otrzymamy wynik wszystkich testów zawartych w klasie. Z kolei polecenie wywołane spoza kontekstu testów jednostkowych nie uczyni nic.
No i po trzecie: dla programistów preferujących zabawę myszką (taa…) mamy ikonki na bocznym pasku VS również upraszczające wykorzystanie z dobrodziejstw unit testing. I ponownie wizualizacja mych wynurzeń:

Mała uwaga: zdaję sobie sprawę że tak naprawdę nie jest to nic wielkiego (w końcu NUnit także ma swój “runner”, podobnie jak i najbardziej rozbudowana wersja VS), jednak nie sposób w końcu nie wspomnieć o tym bardzo ładnie zintegrowanym z VS dodatku.

2) Create type/method/ctor/field from ctor

Ten punkt również poniekąd odnosi się do testów jednostkowych – tym razem niesamowicie wspomaga typowe TDD. Możemy napisać testy dla klasy której jeszcze nie ma, a następnie za sprawą kilkukrotnego wciśnięcia [alt]+[enter] otrzymać jej najprostszą implementację. Nie ma już konieczności ręcznego głupiego i bardzo “błędogennego” pisania nie wiadomo ile razy tych samych deklaracji, identyfikatorów, sygnatur…

3) Move type to file

Kolejny minifeature pozwalający na utrzymanie porządku w kodzie w bardzo prosty sposób. I ponownie – szczególnie przydatny podczas stosowania metodyki TDD. Naprędce wygenerowane na potrzeby najprostszych testów klasy pojawiają się w tym samym pliku co klasa testująca. W tej sytuacji R# zaproponuje nam utworzenie pliku o nazwie takiej jak klasa i automatyczne przeniesienie do niego jej zawartości. Niby nic, a w praktyce naprawdę sweet.

4) Introduce variable

Funkcja bardzo znacznie przyspieszająca tworzenie kodu. Przykład z klasy zawierającej testy, ale po przyzwyczajeniu nieustannie wykorzystuję ów feature wszędzie gdzie to możliwe. Ile czasu, tudzież wciśnięcia ilu klawiszy, wymaga napisanie następującej linii?:

IFoo foo = _mockery.CreateMock<IFoo>();

Po kolei: _m.CM<IF>[enter][alt+enter][enter][enter]. Koniec! Piękne. Rozwijać tych szlaczków nie będę, zainstalujcie i przekonajcie się sami:).

5) Generowanie foreach

Jest do tego snippet w VS, jednak wypada on przy tej funkcji R# jak to przy kimkolwiek jakiejkolwiek płci. Od ziomków z Jetbrains otrzymujemy do wyboru wszystkie obecne w aktualnym kontekście kolekcje, typ oraz inteligentnie zasugerowaną nazwę zmiennej tymczasowej do wyboru! Oto wizualizacja:

6) Put into using construct

Kolejny czasozdobywacz, i więcej! Omawiana funkcja nie tylko wstawi nam blok ‘using’ wokół całego kodu korzystającego z danego obiektu implementującego IDisposable, ale również wskaże takie obiekty nawet wówczas, gdy JAWNIE implementują ów interfejs (explicit implementation)! A bez uciekania się do Reflectora bądź dokumentacji ciężko było takie bestie zidentyfikować. Tu także mały sampl:

7) Templates

Mechanizm szablonów jest bardzo podobny do Snippetów znanych z Visual Studio. Czym się więc różni? W VS nie ma standardowo prostej możliwości edycji istniejących snippetów bądź dodania własnych, wymagane jest ręczne grzebanie w xml. O żadnym dodatku do tego służącym także nic mi nie wiadomo, ale przyznaję że takowego nie szukałem. Ze snippetów w VS właściwie nie korzystałem, dodawałem zawsze jedynie dwa własne (cr dla Console.ReadLine() oraz dw Debug.WriteLine()) i tyle. Dopiero po zainstalowaniu R# tak naprawdę doceniłem ten potężny mechanizm.
Resharper oferuje trzy typy szablonów, każdy z nich jest banalny w tworzeniu i edycji, umożliwiającej oczywiście definiowanie parametrów: “surround template” (np #region), “file template” (nowa klasa, nowy interfejs…), “live template” (standardowe elementy używane przy kodowaniu). Ich przewaga nad standardowymi snippetami z VS nie ogranicza się do posiadania wygodnego edytora. Gwoździem do visualowej trumny jest możliwość zdefiniowania kontekstu, w którym dany szablon ma być dostępny z Intellisense! Opcji do wybrania jest całkiem sporo, co można zobaczyć na załączonym obrazku:

8) Ostrzeżenia o (szczególnych) potencjalnych błędach

O wypisywaniu błędów/ostrzeżeń przed skompilowaniem aplikacji pisałem już wcześniej. Tym razem jednak wymienię kilka sytuacji, które potencjalnie mogą być bardzo niebezpieczne i niesamowicie ciężkie do zidentyfikowania, a które to R# nam podaje jak na tacy:

• “possible null reference exception”
• “virtual call in constructor”
• “access to modified closure”
• “parameter has no matching param tag in the xml comment but other parameters do”

Dwa mówią same za siebie, jednak dwa pozostałe są dość intrygujące. Nie będę ich tutaj rozwijał, ponieważ scenariusze je powodujące zasługują na osobne posty.

9) Solution-wide analysis

Wspominałem w jednym z poprzednich postów, że R# na bieżąco bada powstający kod i najszybciej jak to możliwe ostrzega nas o powstających błędach. Standardowo tyczy to się jedynie aktualnie edytowanych plików. Istnieje jednak funkcja analizująca naraz wszystkie projekty w bieżącej solucji. Otwierając stare, już istniejące rozwiązanie, i przepuszczając je przez tą analizę można dowiedzieć się naprawdę wielu ciekawych rzeczy:). I nie trzeba chyba dodawać, że takie nieustanne trzymanie ręki na pulsie z pewnością w niczym nie zaszkodzi a może pomóc, szczególnie podczas pracy w zespole. Samo przedstawienie błędów jest zupełnie nieinwazyjne – po prostu w prawym dolnym rogu IDE otrzymujemy kolorowe kółko informujące o aktualnym stanie naszej pracy. Po kliknięciu kółeczko udostępnia proste menu z większą liczbą opcji:

Należy zaznaczyć, że ta operacja może dość mocno spowolnić pracę VS, ale dzięki opcji Pause i możliwości wyłączenia analizy w dowolnym momencie nie stanowi to wielkiego problemu.

10) Oznaczanie zbędnego kodu

Ten feature zasługuje na osobny, pełny punkt. Nawet nie zdawałem sobie sprawy ile śmieci mam w kodzie! Po co zbędne deklaracje using, po co zbędne rzutowanie czy martwe metody (sic!)? Po nic, więc co robimy? Identyfikujemy wyszarzony kod, wciskamy [alt]+[enter]-> WON! E.g.:

11) Complete statement ([ctrl]+[shift]+[enter])

Ta nowa w wersji 4.0, bardzo zachwalana na stronie producenta funkcjonalność ma na celu jedno: dokończyć za nas pisanie kodu, którego treść można bez problemu wydedukować. Dlatego też deklarując metodę wystarczy napisać jej zwracany typ, nazwę i parametry, następnie wcisnąć wymienioną sekwencję klawiszy, i otrzymamy poprawnie sformatowany kod z pustym ciałem metody i kursorem ustawionym tam gdzie trzeba. Szczerze mówiąc nie widzę tu wielkiej rewolucji, ale to może dlatego że jeszcze nie przyzwyczaiłem się do wykorzystywania tej funkcji.

Cóż pozostało do napisania… W trzech odsłonach starałem się przedstawić najbardziej atrakcyjne z mojego punktu widzenia funkcje Resharpera – narzędzia niesamowitego, które całkowicie zmieniło mój sposób interakcji z Visual Studio. Jeżeli udało mi się w ten sposób kogoś nakłonić do jego używania (ku mojej satysfakcji słyszałem to już od 3 osób) to super. Jeżeli nie udało mi się to odsyłam na stronę producenta, gdzie znajdzie więcej informacji i może w ten sposób da R# szansę:). Happy Resharping!

I jeszcze P.S.: trzykrotne bicie pokłonów zdecydowanie wystarczy. Mam nadzieję umieścić w przyszłości post zatytułowany “11 wad Resharpera”. Na razie jednak nie mam materiału nawet na połowę takiego wpisu, więc nie mogę zagwarantować że się kiedykolwiek ukaże.