devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
9 minut

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


11.06.2008

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.

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
jakubin

Kolejny świetny post z cyklu R#. Gratulacje!
PS. Uważam, że JetBrains powinien płacić Ci prowizję od wzrostu sprzedaży w Polsce ;).

brejk

Normalnie jakbym czytał Tadzia Golonkę piszącego o Zune :D Ale dobrze się to czyta. Tak trzymaj, Maciek!

arkadiusz.wasniewski
arkadiusz.wasniewski

W 4 wersji ReSharpera jedno mnie drażni. Uporczywe namawianie do zmiany typów zmiennych lokalnych na var. Ale już podpowiedzi kiedy lambda a kiedy nie to po prostu rewelacja! No i poprawili problemy jakie miała wersja 3.x z projektami, gdzie kod z jednego projektu był powiązany (link) z drugim projektem –  wtedy ReSharper czasem głupiał i pokazywał masę błędów. Teraz tego nie ma.

Marcinii
Marcinii

A druga strona medalu?
Wszystko pięknie ładnie, a może teraz byśmy przeczytali kolejną szczęśliwą jedenastkę ale o tym dlaczego nie warto używać Resharpera?
Po przeczytaniu dwóch poprzednich części tego cyklu nawet zainstalowałem Resharpera – może żyję w innym świecie ale po dwóch tygodniach pracy powiedziałem “dość” dla tego narzędzia i w tej chwili go nie używam. W sumie nie będę wymieniał teraz wad jakie zaobserowałem mam nadzieję, że uczyni to nasz guru z tego bloga :)
Pozdrowienia
Marcin Iwanowski

Procent

@jakubin: Jesli czujesz nieodpartą chęć to napisz do nich maila że jest taki kolo % ktory moze skorzystac z ich sponsoringu, nie obrażę się;). @brejk: Taa, kiedys widziałem gdzies jakąś wypowiedź TG o Zune. Może nie powinno tak być, ale moim zdaniem R# zasługuje w pelni na balwochwalcze lizanie z mojej strony, gdyż jest naprawdę debest:) @arkadiusz.wasniewski: Sugestię zmiany typu na var można przecież wyłączyć: Resharper -> Options -> Inspection Severity -> Code Redundancies -> 2 ostatnie opcje. Wystarczy zaznaczyć “Do not show” i mamy spokój. @Marcinii: Tak jak napisalem pod koniec posta, bardzo chetnie przedstawilbym “R# – wady –… Read more »

Marcinii
Marcinii

Nie chciałem tego pisać :P Na początku chciałbym zaznaczyć że używałem, którejś z najnowszych wersji Resharpera 4, jednakże nie była to jeszcze wersja finalna. Co do wad (w tych punktach wymienię tylko! wady), które jednak odepchnęły mnie od używania Resharpera: 1. Ilość funkcji resharpera – kontrowersyjne stwierdzenie? To może napiszę jak te wszystkie funkcje resharpera wyglądają od mojej strony (użytkownika), a więc aby poprawić swoją wydajność podczas pisania kodu jestem zmuszony (tak to dobre słowo do tego przypadku) pamiętać wszystkie opcje jakie proponuje mi resharper, opcje + skróty klawiaturowe (wiadomo, że częste używanie myszki spowalnia proces wytwarzania oprogramowania), w wypadku… Read more »

Procent

Dzięki za tak wyczerpujący opis! Robię się zbyt słodki w stosunku do Jetbrains, ale niestety moja odpowiedź będzie raczej odpieraniem wymienionych zarzutów… 1) “Liczba funkcji” jest pojęciem względnym, równie dobrze możesz używać R# jedynie do nawigacji pomiędzy plikami/klasami (to był główny powód rozpoczęcia mojej przygody z tym narzędziem) a resztę wyłączyć. Przyznaję że na początku można się w tym pogubić, ale już w pierwszym poście ostrzegałem że przyzwyczajenie może zająć trochę czasu. Dodatkowo na stronie producenta jest dostępny mały pdfik (chyba 1 strona) z najbardziej przydatnymi skrótami – znacząco przyspieszył on u mnie proces “przyzwyczajania się”. 2) Szybkość intellisense –… Read more »

arturstan
arturstan

“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.”
Korzytam z Code Snippet Editor. Całkiem, całkiem. Robić to w xml-u, to nie na moje zdrowie ;)
Jeszcze jest Snippy, wg mnie, mniej wygodny.
Artykuły bardzo fajne i pomocne. Dzięki.

Marcinii
Marcinii

A zapomniałem dodać jeszcze jednego powodu dlaczego w tej chwili nie używam resharpera – nie mam na niego licencji :) – pracuję w bardzo młodej firmie i na razie musimy liczyć się z kosztami – a staramy się robić wszystko legalnie.
Póki co zostaję przy używaniu Microsoft Source Analysis for C# – wymaga troszkę wkładu w tworzeniu kodu, ale polecam wszystkim, którzy chcą zachować porządek w swoim kodzie.
Pozdrowienia
Marcin Iwanowski

yaceq
yaceq

a tak na marginesie patrzac od innej strony na efekt dzialania R# – nie masz czasem mysli ze zaczyna Cie za bardzo zwalniac z myslenia? jako MVP na pewno myslisz (o ile juz nie masz) o egzaminach MS.. R#, wiem z wlasnego doswiadczenia moze az za nadto zwolnic z myslenia, a poziom ‘upiekszenia’ kodu przez R# pozostawia czasem wiele do zycenia (mowie o standardowych ustawieniach)… wszystko to moze utrudnic np nauke do egzaminow kiedy w duzej czesci R# za Ciebie programuje… Podobnie do Marcina po Twoim pierwszy poście, postanowilem zainstalowac R# wiedzac, ze jego egzystencja potrafi bardzo negatywnie wplynac na… Read more »

jakubin

@yaceq: Dlaczego uważasz, że zwalnia z myślenia? Przecież R# co najwyżej podpowiada najbardziej powtarzalne kawałki kodu (albo ma genialne funkcje, o których nie wiem :)).
Też muszę się przyznać, że R# na początku mnie trochę przeraził, ale jak poużywałem go dłużej, to bardzo szybko się uzależniłem, choć pewnie nadal wykorzystuje z 20% jego możliwości. Co do wydajności, u mnie tak bardzo nie zwalnia, żeby mnie zniechęcało, a używam go przy sporym projekcie. Ale może ja mam jakąś zwiększoną cierpliwość – w końcu należę do nielicznych lubiących Vistę ;).

yaceq
yaceq

@jakubin: no nie wiem – ja odczulem wyrazny spadek wydajnosci… moze dlatego ze za malo ramu? nie wiem… ale wg mnie chodzil czasem za wolno.. co do upiekszania kodu to mozna podac juz wielokrotnie wspominany przyklad podstawiania var’a – probowalem to wylaczyc a mimo to jakas tam zaroweczka zawsze mi sie pokazywala… co do zwalniania z myslenia – mnie troche wlasnie zaczely przeszkadzac udogodnienia od R# ktore wg mnie mogly miec negatywny wplyw na moja wiedze z C# jako ze R# moze sie stac mniej wiecej taka proteza co za Ciebie wszystko robi… czasem wg mnie lepiej jest napisac wieksza… Read more »

Procent

@yaceq:
Dzięki za krytyczny komentarz – krytyka zawsze lepsza od pochwał:).
Mimo to muszę precząco odpowiedzieć na zadane pytanie “nie masz czasem mysli ze zaczyna Cie za bardzo zwalniac z myslenia?”. I szczerze mówiąc nie za bardzo widzę związek pomiędzy R# a nauką do egzaminów – jedyny wpływ R# na moją pracę to szybsze kodowanie i mniejsza liczba popełnianych błędów…

Moja książka

Facebook

Zobacz również