Coding standards, cz. 2 – ogólne zasady pisania dobrego kodu

Witam w kolejnej odsłonie „Coding Standards”. Nadal nie mam czasu na skończenie kontrolki GoogleMaps, która wygrała ankietę, dlatego proponuję wpis kontynuujący szumnie zapowiadaną serię ;-)

W dzisiejszym odcinku zajmiemy się ogólnymi zasadami „dobrego” programowania. Mam nadzieję, że uda mi się ogrom informacji sensownie posegregować. Let’s go.

1. Wszystkie pola w klasach deklaruj jako prywatne

Wyjątek: pola oznaczone jako readonly lub const.

2. Przeciążone metody powinny mieć podobne zachowanie i być wykorzystywane w zbliżonych celach

Nie stosowanie tej zasady podpadać może pod łamanie innej ;-) – tzw. zasady najmniejszego zaskoczenia (principle of least surprise).

3. Używaj instrukcji warunkowych (switch-case, if-else) gdy jakieś działanie zależy od wartości obiektu, nie od jego typu.

4. Instrukcje warunkowe obejmuj nawiasami klamrowymi

Wszystkie bloki warunkowe if-else, while, do-while, switch-case obejmuj w bloki nawiasami klamrowymi. Nawet, jeśli zawierają tylko jedną instrukcję. Ta zasada zapewne wielu wyda się kontrowersyjna, ale jestem ogromnym zwolennikiem jej stosowania. Zdecydowanie wolę czytać:

zamiast

5. W switch-case zawsze umieszczaj default

nawet jeśli nie wykona on żadnej akcji i znajdzie się tam tylko komentarz. Pozostawi to jasność sytuacji.

6. Pamiętaj o Liskov Substitution

… czyli o tym, że zapewniona powinna być możliwość użycia referencji do obiektu klasy pochodnej wszędzie tam, gdzie użyta jest referencja do obiektu będącego instancją jego klasy bazową. Jest to zasada Liskov Substitution.

7. Szereguj atrybuty, właściwości oraz metody według poziomu dostępu

Deklarując pola, property i metody w klasie szereguj je w pliku wg poziomu dostępu: public, protected, private

8. Kolejność ustawiania / pobierania properties nie może mieć znaczenia

Zapewnij możliwość ustawiania właściwości (Property) klasy w dowolnej kolejności. Nie powinna zdarzyć się sytuacja, gdy nie ustawienie jednego property przed ustawieniem innego spowoduje nieprawidłowe zachowanie.

9. Property – tam, gdzie potrzebny jest prosty dostęp do danych

Używaj właściwości (Property) wszędzie tam, gdzie zapewniają one prosty dostęp do danych.

10. Metody – tam, gdzie dzieje się „coś więcej”

Używaj metod wszędzie tam, gdzie odbywa się „coś więcej” niż tylko dostęp do danych. Nad tym problemem dość mocno pochyla się Jeffrey Richter w CLR via C#, wskazując więcej wad niż zalet properties’ów i zalecając używanie metod. Generalnie metody należy stosować, gdy:

• odbywa się konwersja danych (np. ToString(), ToInt32() itp.)
• operacja może być na tyle czasochłonna, że niezbędne może być cache’owanie wyników
• wywołanie property dwa razy pod rząd może dać inne wyniki (patrz principle of least surprise)
• kolejność wykonywanie jest istotna
• gdy pole, do którego odnosi się property jest statyczne ale jego wartość może być zmieniona
• gdy zwracana jest kopia obiektu referencyjnego
• gdy udostępniony byłby tylko akcesor set property – wtedy zdecydowanie zastąp property metodą SetSomething(…)

11. Konstruktor ma inicjować obiekt. Cały.

Nie twórz konstruktora, który w całości nie zainicjalizuje obiektu (wszystkich jego pól)

12. EIMI używaj tylko tam, gdzie jest to niezbędne i robisz to świadomie

Używaj EIMI (explicit interface method implementation) tylko wtedy, gdy jest to niezbędne do rozwiązania problemu zduplikowanych nazw.[1] wtedy, gdy jest to uzasadnione. Rób to świadomie – pamiętaj, że implementacja metody interfejsu wprost jest ukryta przed obiektami dziedziczącymi z klasy, w której się to dzieje i dostęp do takiej metody będzie dostępny wyłącznie po jawnym rzutowaniu instancji na interfejs.

13. Po użyciu operatora as sprawdź czy obiekt nie jest nullem

Gdy używasz operatora as do rzutowania, zawsze sprawdzaj czy wynikiem tej operacji nie jest null. Zawsze. NullReferenceException nigdy nie wybacza.

14. Implementujesz przez override Equals, operator == lub GetHashCode – nie zostawiaj ich samych

Gdy decydujesz się na override metody Equals, operatora == lub metody GetHashCode – zaimplementuj wszystkie trzy.

15. Oczekujesz konkretnej wartości w parametrze lub zwracasz konkretną wartość – używaj enum

Używaj typu enum do konkretnie zdefiniowanych parametrów i zwracanych wartości – to zwiększa czytelność.

16. Wykonujesz operacje bitowe na wartościach enum – użyj [Flags]

Gdy planujesz używać operacji bitowych na typie enum oznacz go atrybutem [Flags]

17. Nie lubimy „magicznych liczb”

Nie używaj „magicznych” liczb. Jeśli coś jest zdefiniowane na stałe – użyj const lub readonly. Bo kto się domyśli, że linia w Twoim kodzie:

oznacza, że w tym autobusie może siedzieć maksymalnie 45 osób?

18. Unikaj rzutowania z obcięciem

Nie wykonuj rzutowania, które może spowodować utratę precyzji (np. z long na int32) – chyba, że zagwarantujesz jego poprawność

19. Długie linie kodu to zło

Nie twórz długich linii kodu – utrudnia to czytanie i zrozumienie kodu. W C++ przyjeła się długośc linii na poziomie 80-90 znaków, C# ma trochę dłuższe namespace’y – ja 120 znaków uznaję za maksimum.

20. Konsekwentny bądź

Jeśli zdecydujesz się na styl pisania kodu (wcięcia, stosowanie nawiasów klamrowych w specyficzny sposób) – trzymaj się go konsekwentnie w całym kodzie.

21. Twardy bądź – nie zmieniaj wartości parametru, na którym opierasz iterację pętli for

Oczywiście nie zmieniaj go dodatkowo wewnątrz pętli.

22. Skromny bądź – prostota zapisu to cnota

Nie ma potrzeby porównywania wartości typu bool do wartości true lub false. Wystarczy zwykłe:

Podobnie zamiast konstrukcji:

zdecydowanie łatwiej napisać:

Zapamiętaj również – trójwarunkowy operator logiczny przyjacielem każdego programisty :) Zamiast:

napisz:

lub jeszcze prościej:

23. Jedno wejście – jedno wyjście. Unikaj wielu instrukcji return

Unikaj wielu instrukcji return w metodach. Złota zasada brzmi „jedno wejście – jedno wyjście”. Oczywiście tego warunku używaj z głową. Jeśli oczywiste jest niespełnienie jakiegoś założenia na samym początku i będzie to jasne dla czytającego kod – od zasady można odstąpić.

---

23 zasady… Tak się właśnie zastanawiam, czy to w ogóle realne zebrać wszystko w jakąś całość.. No nic – będę próbował. Ja „prześpię” się z tematem – być może przydałaby się część B ninejszego odcinka – tymczasem kurtyna podniesiona. Zapraszam do komentowania. Co według Was pominąłem, z czym się nie zgadzacie?

Przypisy

1. zmodyfikowane po komentarzu hamera↩

Podobne wpisy
Coding standards, cz. 1 – konwencje nazewnictwa
Coding standards – intro