Backend

Zasady czystego kodu C# w pigułce

10 kwietnia 2019 Dawid Kraczkowski

Używaj nazw, które coś znaczą, używaj konwencji i nie produkuj nieużywanego kodu. To tylko kilka z generalnych wskazówek dotyczących zasad czystego kodu, które znajdziecie w tym artykule.

Lista tipów na temat czystego kodu

1. Używaj nazw, które coś znaczą

Nieważne czy chcesz nadać nazwę zmiennej, metodzie, klasie, podprojektowi czy czemukolwiek innemu. Na tym etapie zapamiętaj jedną prostą zasadę. Twoja nazwa musi mieć sens. Zapomnij o beztroskim wklepywaniu „s”, “field1”, “list”, “array” czy “asdfg”. W czasie, gdy kod będzie powoli rósł, przypadkowe nazwy staną się zaczątkiem chaosu.

2. Używaj konwencji

Konwencja to nie tylko zbiór zasad o tym, jak pisać dobry kod. To schemat, zgodnie z którym powinna działać każda osoba w zespole. Jeśli Ty i Twój team nie przepadacie za domyślnymi konwencjami Waszych języków programowania, stwórzcie swoją własną. Później wystarczy się jej trzymać.

3. Nie produkuj nieużywanego kodu

Wyobraź sobie następującą sytuację. Wrzucasz do lodówki mięso, które ma krótki termin ważności. Nie chcesz marnować jedzenia. Postanawiasz, że jutro zrobisz z niego klopsy. Przychodzi następny dzień. Okazuje się, że po pracy jesteś zbyt zmęczony, żeby brać się za gotowanie. Po prostu zamawiasz pizzę. Następnie wyjeżdżasz na tydzień, na długo wyczekiwane wakacje.

Po powrocie okazuje się, że mięso jakimś dziwnym sposobem nadal tkwi w lodówce. Z tą różnicą, że teraz niemiłosiernie śmierdzi. A wraz z nim cała lodówka. Podobnie jest w przypadku nieużywanego kodu. Łatwo się go pozbyć, kiedy jest świeży, w zasięgu wzroku. Jeśli jednak leży odłogiem tygodniami, ciężko będzie znaleźć ochotnika na tyle odważnego, żeby się go pozbyć.

4. Zwracaj uwagę na strukturę

Nie pisz klas modeli w miejscu, w którym przechowujesz usługi. Powinieneś z łatwością odnajdywać obiekty konkretnego typu i wiedzieć, do czego służą.

5. Nie pisz komentarzy i nazw zmiennych w swoim ojczystym języku.

Cieszę się, że jesteś dumny ze swojego ojczystego języka. Jednak programiści powinni znać i posługiwać się jednym podstawowym językiem obcym — angielskim. Wtedy istnieje wysokie prawdopodobieństwo, że międzynarodowi koledzy po fachu, którzy będą mieć do czynienia z Twoim kodem, zrozumieją go.

6. Tego wystrzegaj się jak ognia!

NIGDY nie pisz nazwy metody, która mogłaby sugerować coś innego niż jej zawartość. To bardzo prosty przepis na uniknięcie katastrofy.

7. Używaj wzorców projektowych…

…TYLKO jeśli są naprawdę potrzebne. Widziałem dziesiątki potężnych projektów bez jakichkolwiek wzorców i setki takich, w których zostały użyte w niewłaściwy sposób. Oba przypadki są niebezpieczne dla całości kodu.

8. Nie pisz klas ze zbyt dużą ilością linijek kodu

W ten sposób sprawiasz, że kod staje się łatwiejszy do analizy. Pisz rozważnie, zostawiaj tylko te niezbędne.

9. Pisz testy jednostkowe

Są bardzo przydatne w dużych projektach. Dzięki nim możesz sprawdzić, czy wszystko działa tak jak powinno. Zanim zabierzesz się za pokrywanie nimi kodu, naucz się jak pisać je poprawnie. Źle napisane testy jednostkowe mogą spowodować więcej kłopotów niż ich brak.

10. Uzupełnienie zasady o nieużytym kodzie

Chcę rozszerzyć temat z punktu numer 3. Pod żadnym pozorem nie pisz martwego kodu. Na późniejszych etapach pracy może być trudny do wykrycia.

11. Wykorzystuj ponownie raz napisany kod

Twój, Twoich kolegów, a także fragmenty kodu specyficzne dla Twojego języka programowania. Staraj się tworzyć kod wielokrotnego użytku. Trend zero waste ma zastosowanie również w IT!

12. Poświęć trochę czasu na nauczenie się nowych rzeczy

Skończyłeś swoje zadania wcześniej? Świetnie! Teraz możesz dowiedzieć się, jak pracować skuteczniej i podnieść swoje umiejętności.

13. Jeśli Twój język programowania wspiera stałe, użyj ich wszędzie tam, gdzie są potrzebne.

14. Nie “zakomentowuj” kodu

Przychodzisz na miejsce innego programisty. Masz pracować z kodem, który wcześniej stworzył. Chcesz dokonać zmian, co robisz? Mam nadzieję, że nawet nie próbujesz zrobić z niego komentarza i dodać nowy kod jak gdyby nigdy nic! Zakomentowany kod zmniejsza przejrzystość.

15. „Jestem zmęczony, napiszę tu sobie komentarz ToDo i ogarnę to później”

Z pewnością… Czy mówiąc „później” miałeś na myśli „nigdy”? A tak na serio, możesz napisać komentarz ToDo kiedy kończysz danego dnia pracę i musisz wiedzieć, od którego miejsca zacząć jutro. Nigdy nie zostawiaj ToDo jeśli wiesz, że później i tak się za to nie zabierzesz.

16. Używaj odpowiednich wcięć, formatowania kodu itd.

Spraw, aby Twój kod wyglądał pięknie. Spraw, aby czytanie go było bułką z masłem.

17. Nie zagnieżdżaj kodu poza limitami szerokości ekranu

Kod powinien być czytany w pionie, nie w poziomie.

18. Nie używaj magicznych liczb

Weź pod uwagę fakt, że nie każdy wie co w Twoim kodzie oznacza „-1” czy „10”. Używaj stałych, w razie potrzeby wstaw komentarze objaśniające znaczenie tych liczb.

19. Staraj się nie tworzyć zbyt obszernych metod

Podziel je na mniejsze kawałki. Może się okazać, że później będziesz w stanie użyć ich ponownie.

20. Nie pisz kilku instrukcji w jednej linijce

21. Nie używaj przestarzałej technologii

Jeśli miałeś zamiar napisać jakiś kod w technologii, która nie jest już rozwijania, pomyśl dwa razy zanim podejmiesz ostateczną decyzję. Pamiętasz przykład z lodówką?

22. Używaj konstrukcji zgodnie ze swoimi potrzebami.

Możesz osiągnąć ten sam efekt stosując różne metody. Szukaj tych, które najbardziej Ci odpowiadają.

Zapewne mógłbym podać Ci jeszcze więcej tipów, ale obawiam się, że niewiele osób wytrwałoby do końca. Zachęcam Cię do przeczytania i zrozumienia „Clean Code” Roberta C. Martina. Uważam, że zasady czystego kodu przedstawione w niej są nadal aktualne.

Zasady czystego kodu w praktyce

Blok kodu

Blok kodu wspomniany wyżej jest trudny do przeczytania. Możesz usunąć część kodu i dodać kilka linijek, aby zwiększyć czytelność.

Recykling kodu

Ważnym aspektem bycia programistą jest sprawdzanie, czy pewna funkcjonalność wystąpiła już w dostępnych bibliotekach. Tutaj mamy przykład, w którym zostało stworzone „delegate” mimo że istnieje już taki fragment kodu.
Zróbmy refaktoring tego kodu.

Nadal występuje tu zdarzenie, ale teraz ma wbudowany typ. Dodatkowo dzięki specjalnej konstrukcji („?” check for null) możesz skrócić inwokację. Ponadto pozbywając się konstrukcji new EventArgs, zwiększysz nieco wydajność.

Lepsza konstrukcja

Tutaj możesz wprowadzić jedynie kilka kosmetycznych poprawek. Choć niepozorne, sprawiają, że kod staje się bardziej czytelny. Takie szlify również są częścią praktyk czystego kodu.

Wyłapywanie wyjątków

Tutaj mamy ciężki przypadek. Widziałem podobną konstrukcję w działającym projekcie! Sprawdźmy co jest nie tak z tym kodem:

MethodWithReturn zwraca bardzo ogólny typ

MethodWithReturn w jednym przypadku zwraca Wyjątek

Jak pewnie widzisz, wyjątek nie jest użyty poprawnie. Ogólnie rzecz biorąc, takie obiekty nie powinny być zwracane. Mimo to logika tej aplikacji jest kontrolowana poprzez zwracanie typu obiektu. Okropność!

Spójrz na ten kod. Ciągle zwraca typ obiektu, ale przynajmniej teraz z użyciem mechanizmu wyłapywania wyjątków.

Nieadekwatna konstrukcjaTutaj mamy świetny przykład, w którym możesz użyć „foreach” zamiast „for”.

Obie wersje wyglądają podobnie. Jednak drugi wariant używa pętli, która jest przeznaczona do tego typu iteracji.

Sprawdzanie list

Lista liczb całkowitych jest pusta. Nie ma sensu sprawdzać, czy posiada jakieś elementy, ponieważ pętla „foreach” zrobi to automatycznie za nas.

Wcięcie!

Widziałem takie okropne konstrukcje zbyt wiele razy i nie chcę ich już spotykać. Na szczęście istnieją wspaniałe narzędzia, które mogą automatycznie posprzątać taki zapuszczony kod.

Magiczne liczby

Z pewnością wiesz, co oznaczają te liczby? Serio, używajmy stałych!

Widzisz? Teraz nie muszę wiedzieć, który numer odpowiada za stan „prawidłowy”. Co więcej, mogę pozmieniać zmienne jak tylko mi się podoba, a każde odniesienie dostosuje się do tych modyfikacji.

Zbędny kod

Tu mamy do czynienia z powtórzeniem kodu. Wyciągnijmy je z nawiasu.

Zagnieżdżone instrukcje

W tym przypadku nie ma wielu linijek kodu. Możemy jednak zredukować ilość nawiasów i zagnieżdżonych bloków za pomocą jednego prostego tricku.

Złe typy

Ten fragment kodu jest ostatnio w mojej osobistej czołówce. Musisz tylko użyć odpowiednich typów. Od razu widać różnicę!

Dotrwaliśmy do końca! Mam nadzieję, że dużo się nauczyłeś. Teraz możesz wrócić do swojej pracy i dostarczać lepszy kod.

Jeszcze więcej wiedzy dla Ambitnych Bestii

1. https://blog.codinghorror.com/code-smells/ — Tak, wiem, wpis jest z 2006 roku. Mimo to ani trochę się nie zestarzał. Znaki ostrzegające przed kiepskim kodem pozostały takie same.

2. https://sourcemaking.com/refactoring — Wszystko, co chcesz wiedzieć o refaktoringu.

3. Pierwsza część mojego poradnika na temat zasad czystego kodu w języku angielskim.

Zobacz też