Czysty kod

według Roberta C. Martina
Clean Code

Ogólne zasady

Wybór i kolejność moja

Zasada skautów

Zostaw obozowisko w lepszym stanie

niż je zastałeś.

Clean Code, strona 14

Zasady zespołu

Zepół programistyczny powinien zgodzić się na wspólny styl formatowania, który będzie praktykowany i pilnowany przez wszystkich.

Clean Code, strona 90

Szczegółowe zasady

Wybór i kolejność moja,
dużo slajdów przed nami :)

Nazewnictwo

Clean Code, rozdział 2

Nazewnictwo

Przede wszystkim nazwy powinny być:

• Łatwe do wymówienia,
• Łatwe do wyszukiwania,
• Intuicyjne.

Nazewnictwo

Generalnie nazwy powinny przekazywać zamiary programisty.

Nie
int d; // elapsed time in days

Tak
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

Nazewnictwo

Nazwy nie powinny wymagać mental mappingu.

Przykład: Zamiast jednoliterowych liczników w pętlach np. i powinno używać się docelowych konceptów, np. customerIndex.

Nazewnictwo

Nazwy metod powinny być czasownikami, mieć uzgodniony słownik słów kluczowych.

Przykłady potencjalnych słów kluczowych: fetch, retrieve, get.

Nazewnictwo

Nazwy powinny czerpać ze wzorców projektowych, jeśli są adekwatne.

Na przykład: coursor, queue, view.

Nazewnictwo

Nazwy powinny mieć sens w kontekście w którym występują.

Nazewnictwo

Funkcje

Clean Code, rozdział 3

Funkcje

Przede wszystkim funkcje powinny:

• być bardzo, bardzo krótkie,
• robić tylko jedną rzecz,
• nie mieć skutków ubocznych - robić tylko tę rzecz na którą wskazuje nazwa,
• dotyczyć jednego poziomu abstrakcji.

Funkcje

Jeśli wewnątrz funkcji jest zagnieżdżenie, powinno być odwołaniem do innej funkcji.

Funkcje

Funkcja powinna mieć minimalną możliwą liczbę argumentów.

Należy unikać argumentów - flag, lepiej rozdzielić funkcję na dwie.

Należy unikać argumentów "wyjściowych".

Potencjalne długie listy argumentów można przekształcić w obiekty.

Funkcje

Jeśli wystąpił błąd, funkcja powinna rzucać wyjątek zamiast zwracać kod błędu.

Komentarze

Clean Code, rozdział 4

Komentarze

Generalnie komentarze powinny:

• być łatwe w zrozumieniu,
• być używane tylko w razie konieczności,
• tłumaczyć intencje programisty tylko jeśli nie dało się ich przekazać kodem,
• ostrzegać przed zaskakującym działaniem funkcji.

Komentarze

Nigdy nie mogą być zastępstwem dla jasnego, czytelnego kodu.

Formatowanie

Clean Code, rozdział 5

Formatowanie

Zmienne powinny być zadeklarowane w pobliżu miejsca ich użycia.

Zmienne instancyjne powinny być zadeklarowane na górze klasy.

Funkcje zależne powinny być zdefiniowane w pobliżu funkcji je wykorzystujących.

Obiekty versus
struktury danych

Clean Code, rozdział 6

Obiekty vs struktury

Struktury danych oferują zamknięty zbiór metod, wymagają wiedzy o przechowywanych danych do wykonania operacji "biznesowych".

Obiekty vs struktury

Obiekty powinny ukrywać wewnętrzną organizację danych i udostępniać metody manipulacyjne mające sens "biznesowy".

Obiekty vs struktury

Nie

final String outputDir = ctxt.getOptions().getScratchDir()
      .getAbsolutePath();

Tak

ctxt.getAbsolutePathOfScratchDirectoryOption();

ctxt.getScratchDirectoryOption()
      .getAbsolutePath();

Obsługa błędów

Clean Code, rozdział 7

Obsługa błędów

Rzucane powinny być wyłącznie unchecked exceptions.

Użycie checked exception wymaga deklaracji rzucenia tego wyjątku we wszystkich funkcjach w hierarchii wywołań aż do catch.

?

Obsługa błędów

Funkcje nigdy nie powinny zwracać null i nie powinno się nigdy przekazywać null do funkcji.

Testy jednostkowe

Clean Code, rozdział 9

Testy jednostkowe

Cały kod powinien być pokryty testami.

Testy jednostkowe

Pisanie testów powinno być zgodne z trzema zasadami Test Driven Development:

1. Nie pisz kodu produkcyjnego zanim nie napiszesz testu jednostkowego.
2. Nie pisz więcej kodu testów niż jest niezbędne, żeby test się skompilował.
3. Nie pisz więcej kodu produkcyjnego niż jest potrzebne, żeby test przeszedł.

Testy jednostkowe

Testy powinny być:

• napisane równie klarownie co kod produkcyjny,
• rozwijane równolegle z kodem produkcyjnym,
• działać szybko,
• niezależne od siebie nawzajem,
• zawierać tylko jeden assert.

Klasy

Clean Code, rozdział 10

Klasy

Klasy powinny:

• być krótkie,
• być odpowiedzialne za jedną rzecz,
• mieć małą liczbę zmiennych instancyjnych.

Dalsze czytanki

• Rozdział 8 Boundries - posługiwanie się zewnętrznym kodem,
• Rozdział 11 Systems - dobre praktyki projektowania większych systemów w telegraficznym skrócie,
• Rozdział 12 Emergence - koncepcja projektu wyłaniającego się z dobrego kodu "biznesowego",
• Rozdział 13 i załącznik A Concurrency - projektowanie współbieżnego kodu, obsługa błędów,
• Rozdziały 14, 15, 16 - przykłady konkretnych refaktoryzacji,
• Rozdział 17 Smells and heuristics - długa lista potencjalnych problemów i dobrych praktyk.