Clean Code w Ruby czyli kod musi być CZYSTY!

© Rafał "RaVbaker" PiekarskiLRUG 3.07.2012

Kim jestem?

• programista od 8 lat

• znam Ruby/Rails od ponad 5 lat - WorkingWithRails

• ostatnio pracowałem w porównywarce Nokaut.pl

• github: ravbaker

• twitter: @ravbaker

Skąd ten cały szum?

Co to jest czysty kod?

• prosty

• elegancki

• wydajny

• czytelny

• bez powtórzeń (DRY)

• łatwy w rozbudowie

• jak dobrze napisana proza

Zgadzacie się?

Dlaczego warto?

Agenda

• zasada skautów

• znaczące nazwy

• funkcje

• komentarze

• formatowanie

• obiekty i struktury danych

• obsługa błędów

• testy jednostkowe

• klasy

• systemy

Zostaw kod czystszym niż go zastałeś.

Znaczące nazwy

• jeśli nazwa wymaga komenarza nie jest dobrą nazwą: d, af_objects, the_list, a2

• unikaj dezinformacji: controller_for_efficient_handling_of_strings vs. controller_for_efficient_storage_of_strings

• tworzenie nazw które można wymówić: time_ymdhis

• rzeczowniki (lub wyrażenia rzeczownikowe) dla klas i czasowniki (lub wyrażenia czasownikowe) dla metod: AddressParser, Manager, Processor delete_page, save, wait_until

• nie dodawać nadmiarowego kontekstu: LSBAccountAddress

• Celem jest aby opowiadały historię systemu

• Podstawową regułą jest aby były małe - mieściły się na jednym (małym) ekranie

• Powinny robić jedną rzecz!

• Zasada zstępująca i nie mieszanie poziomów abstrakcji

• Nie powtarzaj się! (DRY)

Funkcje

• Nazwy opisowe i wyjaśniające co się dzieje z argumentami: include_teardown_page() check_password(user_name, password)

• Idealna liczba argumentów to... "zero"

• Więcej niż 3 argumenty nie powinno być nigdy używane

• Argumenty-flagi są okropne: render(is_suite) lepiej render_for_suite() i render_for_single_test()

• Unikaj efektów ubocznych

Nie komentuj złego kodu - popraw go.Brian w. Kernighan i P. J. Plaugher

Komentarze

Dobre komentarze Złe komentarze

Publiczne API zamknięcia bloków i tagów

wyjaśnienie zamierzeń zakomentowany kod

ostrzeżenia przed konsekwencjami nadmiarowe komentarze

prawdziwe listy TODOkomentarze niepublicznych

metod

znaczniki pozycji:# #### Action #####

• nie używaj komentarza kiedy możesz to wyjaśnić kodem: x = 10 # assigns number 10 to variable x

• komentarze nie naprawią złego kodu

• licz się z tym, że komentarze mogą zawierać kłamstwa

• celem komentarzy jest wyjaśnić kod, który nie wyjaśnia się sam

Bądź konsekwentny!

Formatowanie

Obiekty i struktury danych

Prawo demeter

• C

• obiektu utworzonego przez f()

• obiektu przekazanego jako argument do f()

• obiektu umieszczonego w zmiennej instancyjnej klasy C

głosi, że metoda f() klasy C powinna wywoływać tylko metody z:

ActiveRecord

• to struktura danych!

• do zasad biznesowych powinny być tworzone osobne obiekty!

Obsługa błędów

• wyjątki zamiast kodów powrotu

• osobne klasy wyjątków dla różnych potrzeb

• nie zwracamy nil

• nie przekazujemy nil

Testowanie

• testy i kod produkcyjny pisany razem!

• staraj się aby testy były czytelne

• testy są tak samo ważne jak kod produkcyjny

• pamiętaj, mając testy łatwiej refaktorować

• jedna asercja lub koncept na test *

• Szybkie (Fast)

• Niezależne (Independent)

• Powtarzalne (Repeatable)

• Samokontrolujące się (Self-Validating)

• O czasie (Timely)

zasada F.I.R.S.T.

Klasy

• Powinny być małe!

• SRP - Zasada pojedyńczej odpowiedzialności

• Organizuj zmiany

Systemy

• separowanie (rozcięcie) problemów

• DCI - Data Context Interaction

• DSL - Domain-specific language

z: single-page-applications-with-coffeescript-polish © Andrzej Krzywda

Dzięki za uwagę

mało? Prezentacja Uncle Boba o Clean Code w Ruby