Formatowanie kodu szybko i bezboleśnie

formatowanie kodu

Formatowanie kodu to jedna z podstawowych czynności jaką możemy zrobić w ramach refaktoryzacji. Jest proste i bezbolesne (pod warunkiem, że w Twoim języku programowania nie programuje się białymi znakami*). Daje szybki efekt w postaci czytelniejszego kodu a to jest bardzo ważne, zresztą pisałem już o tym tutaj.

Formatowanie kodu z automatu

Visual Studio posiada bardzo bogaty system dodatków a jednym z podstawowych to Productivity Power Tools a w nim dwa ustawienia, które nas interesują formatowanie kodu i usuwanie niepotrzebnych usingów. Instalacja jest banalnie prosta. W Tools -> Extensions and Updates szukamy power toolsów i instalujemy.

instalacja power tools

A potem ustawiamy dwie opcje, Tools -> Options -> Productivity Power Tools -> Power Commands

To wystarczy aby automatycznie formatować kod przy zapisywaniu pliku. Proste? Banalnie proste. Od teraz przed zapisem pliku Visual Studio automatycznie będzie formatować nasz kod i juz będziemy kroczek bliżej do trochę bardziej czytelnego kodu.

Jak formatować istniejący już kod

 

Co jeśli mamy już dużo kodu? Co jeśli chcemy sformatować wszystkie pliki w istniejącym – całkiem sporym projekcie? Nie trzeba otwierać każdego pliku w projekcie, wystarczy odpalić ReSharper-a czyli prawdopodobnie najlepsze narzędzie do refaktoryzacji. Później wystarczy mając wybrane na drzewku solution z menu wybrać ReSharper -> Edit -> Code Cleanup i patrzeć jak się samo robi 🙂 Preste? Banalnie proste. Tak posprzątany kod to dobry początek. Jeśli w zespole macie jakieś standardy kodowania, jeśli wąsy wrzucacie na koniec linii albo do nowej linii to te wszystkie rzeczy ustawisz w Resharper -> Settings -> ……. -> Code Style i oczywiście można ustawić różne ustawienia dla różnych języków.

resharper settings

 

*) programowanie białymi znakami to według mnie jeden z gorszych pomysłów bo konia z rzędem temu kto znajdzie błąd w programie jak mu kod wydrukujemy. Konia z rzędem temu kto szybko w najprostszym edytorze znajdzie spacje zamienione na tabulatory albo tabulatory na spacje. Czego nie widać nie powinno być elementem języka programowania i basta. Mamy dosyć problemów z domeną aby jeszcze dorzucać do pieca. Nie zmienia to faktu, że dobrze się tak programuje – nie trzeba tych cholernych nawiasów sadzać tyle, ale co z tego jak się gorzej utrzymuje.

Umarł GitLab niech żyje git czyli co zrobić zepsuje się git

git sie zepsul co robic

Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?

Single Point Of Failure

Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?

Git na ratunek!

Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:


    git remote add backup git@bitbucket.org:.../.....git

    git push backup master

To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.

Czy awaria gita to jakaś tragedia?

No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…

… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.

 

Visual Studio 2015 i upgrade projektu za każdym razem

Visual Studio 2015 jest już od jakiegoś czasu. Instalacja, odpalenie projektu i do przodu. Coś tam się zaktualizowało w projekcie i mogę dalej pracować z nowymi zabawkami. Problem jaki mi się pojawił to w jednym solution ze sporą ilością projektów jeden z nich aktualizował się przy każdym otwarciu projektu.

Projekt, który chciał się aktualizować przy każdym otwarciu Visual Studio to MVC3, który później był migrowany do MVC4. Przy każdym otwarciu upgrade i kopia wszystkich plików i raport w html-u. Zanim na to zwróciłem uwagę, wrzuciłem całkiem sporo gnoju do repozytorium. Poszukując rozwiązania okazało się, że w trefnym pliku csproj wystarczy usunąć:

<FileUpgradeFlags>40</FileUpgradeFlags>
<UpgradeBackupLocation>Upgrade20</UpgradeBackupLocation>
<OldToolsVersion>4.0</OldToolsVersion>

Pozostało jeszcze wywalenie gnoju z repo i już można pracować jak człowiek.

SpecFlow + XUnit

Specflow fajny jest, piszemy scenariusze czytelne dla ludzi a pod spodem szaleje xunit i sprawdza. Jest tylko jedne problem, aktualnie specflow.xunit instaluje xunit 2.0 a do pliku .feature.cs generuje kod:

MyProjFeature : Xunit.IUseFixture

No i klops, IUseFeature już nie jest dostępny w xunit 2. Można jednak sobie poradzić mieszając trochę w pakietach. Po prostu trzeba po instalacji specflow.xunit odinstalować wszystko związane z xunit 2.0 (use the –Force Luke) i zainstalować xunit 1.9.2 i wszystko śmiga. Poniżej zestaw magicznych zaklęć:

install-package -ProjectName "MyProj.Specs" specflow.xunit
uninstall-package -ProjectName "MyProj.Specs" xunit –Force
uninstall-package -ProjectName "MyProj.Specs" xunit.abstractions –Force
uninstall-package -ProjectName "MyProj.Specs" xunit.extensions –Force
uninstall-package -ProjectName "MyProj.Specs" xunit.assert –Force
uninstall-package -ProjectName "MyProj.Specs" xunit.core –Force
uninstall-package -ProjectName "MyProj.Specs" xunit.extensibility.core –Force
install-package -ProjectName "MyProj.Specs" xunit -Version "1.9.2"
install-package -ProjectName "MyProj.Specs" xunit.extensions -Version "1.9.2"