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