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.

Nie będziesz refaktoryzował – będziesz miał dług

Refaktoryzacja – ot kolejne popularne słowo…. nie zupełnie. Pisząc software nie zawsze dokładnie wiemy jak on będzie wyglądał i co finalnie będzie robił – tzn. w danej chwili (zdefiniowanym kwancie czasu, żeby brzmieć mądrzej) zawsze wiemy co będzie robił, tylko z dalszej perspektywy mentalnej – tj. po dłuższym okresie może się okazać, że robi coś zupełnie innego niż początkowo zakładaliśmy. Oczywiście nie ma w tym nic złego, przecież wszyscy jesteśmy teraz agile jednak nie wiedząc co finalnie będzie robił kod, nie zawsze dobrze możemy zaprojektować jego architekturę. Nie wszyscy nie potrafią, John Skeet potrafi, ale to nie podlega dyskusji.

Architektura powoli ewoluuje i żeby nie skończyć z kupą gruzu, należy o nią dbać. Tym zajmuje się refaktoryzacja właśnie. Tzn. nie tylko tym ale między innymi. Jeśli nie dbamy o kod, nazewnictwo, strukturę i cały ten bajzel to powoli małymi kroczkami zbliżamy się do katastrowy. Ten proces niestety jest bardzo powolny – niestety ponieważ przez to łatwo go zaniedbać. Wymówki w stylu “poprawię później”, “później to zmienię”, “później wydzielę do osobnej klasy” częściej pozostają w sferze NIGDY niż kiedykolwiek się materializują a ponieważ nic się nie dzieje z tego powodu to nie ma czym się martwić. Do czasu aż uświadomimy sobie, że grzebanie w tym konretnym kodzie to straszne bagno ale wtedy jest już za późno. Dlatego o kod trzeba dbać, trzeba być jak skaut, zawsze zostawiać kod odrobine lepszym niż się go zastało.

W refaktoryzacji bardzo pomagają testy i to takie testy, które dają nam jedyne słuszne pokrycie kodu – 100%. Jeśli mamy 100% pokrycie kodu testami, to (teoretycznie) wiemy w 100% co robi nasz kod. Jeśli zaczniemy zmieniać jego strukturę, dostaniemy informację czy nasz kod działa tak samo jak przed zmianami czy nie. W sytuacji idealnej możemy zmienić całkowicie architekturę przyspieszając np. działanie programu bez jakiejkolwiek widocznej zmiany dla użytkownika. Jednak aby to zrobić musimy mieć 100%-owe testy. Przez 100%-towe testy rozumiem, takie, które dają 100% pokrycia kodu (czyli nie ma jakiejkolwiek niesprawdzonej linii kodu) i dają 100% bezpieczeństwo, że psująca zmiana zostanie wyłapana. Mając takie testy mamy komfort wprowadzania zmian. Możemy całość przerobić na CQRSy czy inne wynalazki i mieć pewność, że nic nie zepsuliśmy.

Jeśli nie mamy takich testów to może się okazać, że przy refaktoryzacji coś przypadkiem zepsuliśmy. Jeśli to będzie się zdarzać często to coraz rzadziej będziemy refaktoryzować. To zaś będzie prowadziło do psucia się kodu. Ot koło zamknięte.