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:
- Nie pisz kodu produkcyjnego zanim nie napiszesz testu jednostkowego.
- Nie pisz więcej kodu testów niż jest niezbędne, żeby test się skompilował.
- 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.
Czysty kod
By Magdalena Wójcik
Czysty kod
- 1,696