Czysty kod – dobre praktyki programowania

Witam. Chciałbym dziś przekazać Ci kilka porad na temat ładnego i eleganckiego programowania. Kwestia bardzo często pomijana w wielu książkach i poradnikach, a jakże pomocna w codziennej pracy. Jak pisać, żeby nasz kod był zrozumiały dla innych programistów, a przede wszystkim łatwo zarządzalny? Postaram się nieco rozjaśnić ten temat.

Większość programistów spotyka się z pewnym problemem. Mianowicie, wracają po latach do swojego kodu, łapią się za głowy i myślą – “WTF? O co mi tu chodziło!?”. Po kilku godzinach, straconych na wgłębianiu się w naszą zawiłą logikę sprzed lat, albo piszemy rzecz od nowa, albo jeszcze bardziej chaotycznie wprowadzamy poprawki i modlimy się, by nigdy więcej nie grzebać w tym kodzie.

Jeżeli wiecie o czym mówię lub nigdy nie chcecie się dowiedzieć jak to jest, polecam zastosować się do kilku prostych zasad, przedstawionych w dalszej części artykułu.

Pierwsza zasada – “Nigdy nie zakładaj, że już nie wrócisz do tego kodu”

To bardzo powszechne zjawisko wśród developerów, szczególnie amatorskich. “Uff… Skończyłem. Działać – działa, więc spoko. Oddaję do użytku i mam spokój. Nie chcę się z tym już męczyć”. Nieważne, czy piszemy dla klienta czy dla siebie. Zazwyczaj okazuje się, że jednak przyjdzie nam się zmierzyć z nową funkcjonalnością, serwis się rozrośnie i często ponowne wdrożenie się w kod zajmuje nam grube godziny.

Druga zasada – “Pisz tak, by obcy człowiek potrafił odnaleźć się w Twoim kodzie”

To jest dewiza programistów pracujących w zespole. Programując samemu, również powinna nam ona przyświecać. Czasem, w trakcie pisania większego projektu zapominamy, o co chodziło nam na początku. Co dopiero po roku przerwy – skrypt będzie wyglądał równie obco dla nas (autorów) jak i dla innych. Dlatego ważne jest, by programować na tyle zrozumiale, by można było bez problemów nauczyć się naszego rozumowania od nowa.

Trzecia zasada – “Komentarze, komentarze i jeszcze… Komentarze”

Komentarzy nie stworzono tylko po to, by omijać pewne fragmenty kodu bez usuwania go. Sama nazwa wskazuje na ich najważniejszą funkcję – komentowanie kodu. Nie bój się z nich korzystać i komentuj wszystko, co może wydawać się choć trochę niejasne. Jeżeli napiszesz jakąś funkcję, w komentarzu napisz, jakie przyjmuje argumenty, co zwraca i w jednym zdaniu opisz zasadę jej działania. To zajmuje zwykle kilka minut pracy więcej, a zaoszczędza godziny w przyszłym zarządzaniu i modyfikacji.

Czwarta zasada – “Nazywaj zmienne zgodnie z ich przeznaczeniem”

Skoro zmienną możemy nazwać sobie w dowolny sposób, który nie narusza zasad języka, dlaczego mamy z tego nie skorzystać? Jeżeli do zmiennej przypisujemy wiek ucznia, dlaczego nie nazwać jej studentsAge (wiekPacjenta)? Ludzie utrudniają sobie życie stosując różnego rodzaju tempy, x, y, x1, wiekP, wP i inne badziewie. Takie nazwy nic nie mówią, a każda zmienna, poprawnie nazwana według jej zawartości, ułatwia zrozumienie całości.

Piąta zasada – “Funkcje i klasy też”

Co tyczyło się zmiennych, idealnie pasuje również do klas i funkcji. Jeśli funkcja zwraca z bazy danych uczniów w zależności od wieku nazwij ją GetStudentsByAge (po polsku brzmi to trochę gorzej, ale byłoby to coś w stylu PobierzUczniowWgWieku). Taka nazwa coś mówi i nie trzeba szukać jej definicji, żeby wywnioskować co dana funkcja robi.

Szósta zasada – “Nie wpisuj na sztywno tej samej wartości w wielu miejscach”

Ludzie, którzy pisali kiedyś strony z wykorzystaniem suchego htmla pewnie doskonale znają ten ból. Zmienianie identycznego menu nawigacyjnego lub tytułu strony na każdej z podstron osobno bywa męczące. Zastanów się czy nie skorzystać ze zmiennej, jeżeli wpisujesz drugi raz ten sam tekst. Trzeba zawsze dążyć do tego, by nie trzeba było zmieniać tej samej rzeczy w dwóch różnych miejscach.

Siódma zasada – “Żadnego kopiuj wklej”

Chcesz skopiować kawałek kodu do drugiego pliku? Popatrz na punkt wyżej. Kopiując identyczną funkcjonalność przysparzasz sobie więcej pracy, gdyż wszelkie zmiany musisz wykonać w dwóch miejscach. Jeśli np. po kliknięciu na dwa różne przyciski w różnych stanach aplikacji masz podobne efekty, ubierz je w funkcję i podepnij ją pod zdarzenie. Wtedy masz całą funkcjonalność w jednym miejscu, którą można łatwo edytować.

To oczywiście tylko kilka porad dla początkujących programistów. Każdy z biegiem czasu nabiera własnych praktyk. Lepiej, by były to dobre praktyki, ułatwiające życie.

Polecam przeczytać książkę Roberta C. Martina, idealnie zatytułowaną “Czysty Kod”. Z jej recenzją możesz zapoznać się tutaj: http://testerzy.pl/ksiazki-o-testowaniu/recenzja-ksiazki-czysty-kod-podrecznik-dobrego-programisty.