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.
Kolejny świetny post z cyklu R#. Gratulacje!
PS. Uważam, że JetBrains powinien płacić Ci prowizję od wzrostu sprzedaży w Polsce ;).
Normalnie jakbym czytał Tadzia Golonkę piszącego o Zune :D Ale dobrze się to czyta. Tak trzymaj, Maciek!
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.
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
@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 – top 11”, ale nie jestem w stanie… Jednakowoż bardzo chętnie poznam funkcje przez które go odinstalowales, ponieważ ja ZNACZĄCYCH wad nie zauwazyłem (najbardziej irytujące wg mnie jest przenoszenie ustawień między maszynami – a raczej brak owego przenoszenia, przez co całą zabawę z konfiguracją trzeba za każdym razem przechodzić od nowa – oprócz skrótów klawiszowych, czcionek i kolorów, co zapewnia eksport z VS).
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 gdy używam jeszcze standardowych skrótów klawiszowy w Visual Studio i dodatkowo mam zainstalowany programik dzieki któremu zdefiniowałem sobie skróty do różnych narzędzi najczęściej przeze mnie otwieranych – mój mózg odmawia przyjęcia następnych, z biegiem czasu nawet zapominamy że coś jest pod danym skrótem, albo że w ogóle istnieje jakaś opcja (chyba że często czytamy blog Maćka :)
2. Szybkość intellisense – drobne, acz bardzo irytujące, miałem wrażenie że intellisense Resharpera jest jednak trochę wolniejsze od standardowego, dodatkowo czasem jak za szybko pisałem po prostu potrafiło się nie włączyć (nie wiem czy nie była to wina tej wersji Resharpera) – naciskanie dodatkowych klawiszy żeby włączyc intellisense – porażka; dodatkowo intellisense do xaml’a – kolejna porażka; jednak pomimo nie aż tak zaawansowanych opcji (pewnie to dzieki temu) standardowy intellisense spisuje się odrobinę lepiej.
2.5 Mam nadzieję, że finalna wersja nie wywala się tak często jak te wersje testowe i że są poprawki co do obsługi C# w wersji 3.0 (ja się spotkałem z błędami w informowaniu o błędnej składni podczas używania wyrażenia lambda).
3. Kod stał się za bardzo pstrokaty – pewnie można to ustawić, jednak to co dostałem w standardowych opcjach spowodowało moją lekką dezorientację – jak ja nie lubię gdy coś jest podkreślone w kodzie :) chyba znacie to :)
4. Visual Studio zaczął się wolniej uruchamiać? Zauważyłem to gdy prowadząc prezentację chciałem pokazac kilka przykładów, gdzie każdy z przykładów był oddzielnym projektem (oczywiście po pokazanu każdego z projektów zamykałem VS’a), może to znów tylko kolejny bug tej mojej wersji testowej?
5. Resharper vs Microsoft Source Analysis for C# – jak wiadomo Source Analysis narzuca na kod pewien zbiór bardzo sztywnych reguł (oczywiście możemy niektóre z nich wyłączać – nie zmieniać – jednakże moim zdaniem mija się to z celem używania tego narzędzia ale to zupełnie odrębny temat), niektóre reguły wymuszają na nas pisanie troszkę nadmiarowego kodu w stylu słówek this, czy klamr { } przy każdym z if’ów (kwestionowanie reguł Source Analysis też nie jest teraz temat tego komentarza – aczkolwiek przekonałem się, że naprawdę reguły te są bardzo dobrze przemyślane) zaś Resharper traktuje te nadmiarowy kod jako zbędny – można napisać, że przecież Resharpera można bardzo łatwo dopasować do moich wymagań ale właśnie mija się to z celem używania tego narzędzia. Jest wiele opcji, które programista nie powinien dopasowywać pod siebie, to właśnie on (programista) powinien dopasować się pod narzędzie, narzędzie powinno dyktować (nie tyle co styl) “warunki” pisania kodu – jednakże warunki te powinny być tak dobrane aby kod programisty stał się jaśniejszy, a sam proces wytwarzania kodu – szybszy.
Mam nadzieję że, nie zagmatwałem za mocno idei, którą chciałem przekazać.
Pozdrowienia
Marcin Iwanowski
P.S. Maćku masz już połowę materiału do wpisu 11 wad Resharpera, czekamy na wpis :)
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 – tak, to prawda, czasami potrafi odrobinę “zamulić” i jest to ździebko irytujące. Należy się jednak upewnić, że w opcjach (Resharper -> Options -> IntelliSense -> Completion Behavior) mamy ustawione “Automatically show completion list in…” 0 milliseconds. Wydaje mi się (aczkolwiek pewien nie jestem) że w którejś wersji domyślnie była wstawiona dodatnia wartość co oczywiście opóźniało reakcję.
No i ponownie: jeżeli nie odpowiada Intellisense z R# to można w każdej chwili przywrócić standardową, visualową listę. Aha: nie piszę XAML więc na ten temat się nie wypowiem.
2.5) Wersja beta, rc ani finalna nie wywaliła mi się ani razu. Ale poruszam się w zapewne najbardziej przetestowanym ‘obszarze’ (standardowy C# + markup ASP.NET), więc nie wiem jak to jest gdzie indziej.
Co do błędów z wyrażeniami lambda – w nightly builds bywało różnie, teraz jest zwyczajnie – czyli dobrze.
3) Zgadzam się że pstrokaty kod jest fe, strasznie tego nie lubię. Trzeba jednak wybrać jedno z dwojga (a właściwie trojga, jeśli za trzecią opcję przyjmiemy akceptację pstrokatego kodu:) ): albo zmienić swój styl programowania, albo zmienić ustawienia R#. Przypuszczam że standardowe opcje są poustawiane tak, aby dogodzić jak największej liczbie programistów, jednak jasne jest że nie da się od razu dogodzić każdemu.
4) Tak, VS się wolniej uruchamia. Ładowanie projektów także trwa wolniej, ale R# musi przeanalizować wszystkie wykorzystywane biblioteki aby umieć wykorzystać zawarte w nich informacje. Pocieszające jest to, że dzięki cache tylko pierwsza analiza jest długa, każde kolejne uruchomienie trwa u mnie kilka sekund nawet przy dużych projektach.
5) Analiza – R# ma zwracać uwagę programisty na potencjalnie źle napisane sekwencje kodu _podczas tworzenia programu_. W moim przekonaniu praktycznie dowolna konfiguracja tej funkcji jest jak najbardziej na miejscu – dzięki temu można je zdefiniować dokładnie tak, jak wymagają tego zasady w konkretnej organizacji. Nie zgodzę się, że takie reguły powinny być odgórnie zdefiniowane w samym narzędziu. Dlaczego goście z Jetbrains mają mówić mi jak w mojej firmie pisze się kod?
——————–
Bardzo się rozpisałem, ale niestety te argumenty nie przemawiają do mnie. Właściwie sprowadza się to do wydajności (na stronie możemy przeczytać wymagania: “Memory: 1Gb (4Gb recommended)”) lub konieczności konfiguracji narzędzia wedle swoich potrzeb. Cóż…
W takim razie napiszę te kilka punktów, które na razie sam zebrałem jako wady R#:
1) Wspomniany już import/eksport ustawień – a właściwie brak tej funkcji sprawia, że wszędzie musimy wszystko konfigurować od nowa. Mam nadzieję że się mylę i po prostu nie znalazłem odpowiedniego “guzika”.
2) VS działa czasami zauważalnie wolniej
3) Intellisense nie pokazuje sekcji “Exceptions” obecnej w standardowej visualowej “chmurce”
4) Nie ma opcji wygenerowania łańcucha konstruktorów (można wybrać wywoływany konstruktor klasy bazowej, ale nie można z klasy bieżącej).
I to tyle – jeżeli ktoś ma inne niemiłe doświadczenia (poza bugami, których nie da się uniknąć w żadnej aplikacji) to zapewne chętnie wszyscy się z nimi zapoznamy.
“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.
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
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 szybkosc dzialania Solution zwlaszcza gdy ta sklada sie np z 10 projektow, kazdy co najmniej po kilkanascie klas… niestety wrazenia podobne wrazen Marcina i R# wylecial… wg mnie chlopcy z JetBrains odwalili kawal dobrej roboty ale… no wlasnie ale – troszke wg mnie przedobrzyli z iloscia funkcji a przez to i z waga ustrojstwa w pamieci…
@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ę ;).
@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 czesc kodu z palca – zwlaszcza jak na przyklad masz sie przygotowywac do egzaminu od MS…
Tak na marginesie nie chce nikogo przekonywac do tego ze R# to zlo – bynajmniej! jedyne co to chce podobnie do Marcina nakreslic swoja opinie na ten temat i podobnie do niego pokazac ze jak wszystko na tym swiecie ma swoje zady i walety… Zawsze najlepiej jest zainstalowac i sie samemu przekonac do czego wszystkich tak naprawde zachecam bo jest to soft na prawde dobry ale nie kazdemu musi przypasc do gustu tak jak mnie czy Marcinowi – ot tyle :)
@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…