Jak już pisałem w poprzednim poście jestem w trakcie czytania książki Czysty Kod. Podręcznik dobrego programisty. Pomyślałem sobie, że w trakcie czytania będę starał się wypisywać zawarte tam rady. Efektem tychże notatek będzie właśnie ten wpis. Mam nadzieję, że komuś taki spis dobrych zasad w pigułce się przyda. A ja będę miał go w jednym miejscu :)
Zdecydowałem się na wypisywanie porad zgodnie z rozdziałami książki.
1. Znaczące nazwy:
- nazwy przedstawiające intencję
- unikanie dezinformacji
- wymawialne nazwy
- nazwy łatwe do wyszukania
2. Funkcje:
- możliwie jak najkrótsze (max 20 wierszy)
- najlepiej bez lub jedno argumentowe
- pojedyncza odpowiedzialność
- jeden poziom abstrakcji
- bloki try{} catch{} w osobnej funkcji
3. Komentarze:
- jak najmniej (samo komentujący się kod)
- dozwolone komentarze:
- komentarz z rodzajem licencji
- TODO
- komentarze ostrzegające
- nie komentujmy na siłę
- nie zostawiajmy za komentowanych fragmentów kodu
4. Formatowanie:
- małe pliki (klasy) są lepsze niż duże
- u góry klas najogólniejsze metody poniżej coraz bardziej szczegółowe
- pionowe odstępy między segmentami kodu
- funkcja wywoływana zaraz pod funkcją wywołującą
- wiersze maksymalnie 120 znakowe
- spacje wokół operatorów
- wcięcia poziome oddzielające bloki kodu
- spójne formatowanie w całym zespole
5. Obiekty i struktury danych:
- NIE dodawać na ślepo setterów i getterów
- przestrzegajmy prawa Demeter
- unikanie „wraków pociągów”, czyli kodu postaci: a.getB().getC().getD().getZ().doSth();
- unikać hybryd (trochę obiekt, trochę struktura danych)
6. Obsługa błędów:
- wyjątki zamiast kodów powrotu
- NIE zwracamy null
- NIE przekazujemy null
- tworzenie komunikatów błędów z informacją o typie awarii i co miało się wykonać oraz przesłanie ich w wyjątku
7. Granice:
- separacja obcego kodu od naszego
- testy „uczące” obcego kodu
- wzorzec Adapter
8. Testy jednostkowe:
- kod testów jest tak samo ważny jak kod produkcyjny
- czytelność testów
- w testach nie jest tak istotna wydajność
- jedna asercja na test – niekoniecznie
- jedna koncepcja na test
- testy powinny spełniać zasady F.I.R.S.T.
- Fast – szybkie
- Independent – niezależne
- Repeatable – powtarzalne
- Self-Validating – samo kontrolujące się
- Timely – o czasie
9. Klasy:
- organizacja klas (od góry):
- publiczne stałe statyczne
- prywatne zmienne statyczne
- prywatne zmienne instancyjne
- publiczne metody
- prywatne metody
- klasy powinny być małe
- pojedyncza odpowiedzialność (SRP)
- niewiele zmiennych instancyjnych
- zachowanie dużej spójności
