Czysty kod? to się opłaca

clean-code

Początki niemal zawsze są trudne

Jak to w życiu bywa nic nie przychodzi samo. Czasem potrzeba sporo czasu, żeby wypracować pewne swoje standardy, aby dostrzec błędy w swoich nawykach. Jak to czasem bywa niestety nie każdy dostrzega u siebie błędne zachowania, nawyki ale za to u innych widzi “wszystko”. Bywają i tacy ludzie-bez nich byłoby nudno.
Czasem można im doradzać, tłumaczyć ale oni i tak wiedzą lepiej. Co zrobić, nie każdy docenia pomoc. Niektórzy są zamknięci w sobie i myślą, że pojedli wszystkie rozumy, a w rzeczywistości okazuje się, że ich kod nijak ma się do dobrych zasad. Otrzymujemy tzw. “spaghetti code” gdzie uporządkowanie takiego kodu to nie lada wyzwanie.

spaghetti_code

Czysty Kod

clean_code

Z pomocą przychodzi nam książka “Czysty Kod” Roberta C. Martina. Szczerze przyznam się, że nie przeczytałem całej książki, nawet jej większości (cały czas staram się do niej usiąść ale niestety brakuje czasu). Niemniej jednak wyciągnąłem z niej parę dobrych praktyk, a mianowicie:

  • staram się unikać pisania komentarzy
  • nie zakładam, że nie wrócę więcej do kodu (bo niemalże nie zdarza się nie wracać)
  • staram się pisać tak aby inny programista nie miał problemu z odnalezieniem się w kodzie
  • zmienne nazywam zgodnie z ich przeznaczeniem
  • funkcje i klasy mają  jasno określać do czego służą

Mam nadzieję, że jak przysiądę na dłużej do lektury to wyciągnę z niej dużo dużo więcej.

Dobre praktyki

Dobrą praktyką jest stosowanie się do zasady SOLID zaproponowaną przez autora w/w książki. Ale zaraz zaraz ta nazwa nic nie mówi. Za co odpowiada każda litera poniżej:

  • SRP – Single Responsibility Principle (zasada jednej odpowiedzialności) – klasa powinna mieć tylko jedną odpowiedzialność.
  • OCP – Open/Closed Principle (zasada otwarte-zamknięte) – przy zmianie wymagań nie powinien być zmieniany stary działający kod, ale dodawany nowy, który rozszerza zachowania.
  • LSP – Liskov Substitution Principle (zasada podstawienia Liskov) – korzystanie z funkcji klasy bazowej musi być możliwe również w przypadku podstawienia instancji klas pochodnych.
  • ISP – Interface Segregation Principle (zasada segregacji interfejsów) – wiele dedykowanych interfejsów jest lepsze niż jeden ogólny.
  • DIP – Dependency Inversion Principle (Zasada odwrócenia zależności) – wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji.

Źródło Wikipedia :p

Moje standardy

Moje standardy w konkursie “Daj się poznać 2017” wyglądać będą następująco (dotyczy to wszystkich moich aktualnych projektów w C#).

Some_Component – atrybut Name kontrolki (WPF)

ClassName – nazwa klasy

writeCleanCode() – nazwa metody

_private_variable – prywatna zmienna

public_variable – publiczna zmienna

Czy coś pominąłem? Hmm …. chyba nie. A jeśli tak, napiszcie o czym zapomniałem to dodam 😉 Trochę trwało zanim wyrobiłem sobie pewien swój standard i zachęcam każdego do wyrobienia swojego własnego stylu pisania (można również się wzorować na innych programistach) . Oczywiście należałoby dodać do projektu choćby dokumentację z jakich standardów się korzysta (mimo, że powinno to być w zasadzie widoczne na pierwszy rzut oka ale to taki miły dodatek, żeby nie trzeba było się głowić).

Problem może pojawić się, gdy pracuje się w team’ie i nie można się dogadać co do standardu :p

i_am_the_best

Na zakończenie

Polecam wszystkim (sobie również :p) przeczytanie książki “Czysty kod” oraz stosowania się do dobrych praktyk programowania. Na pewno przyjemniej będzie pisać oraz  wracać do kodu. Dodatkowo nie będzie wtedy problemu z przekazaniem kodu kolejnemu programiście.