Dobry kod jest:
- czytelny,
- prosty,
- wydajny,
- minimalny,
- łatwy do zmiany,
- posiada testy,
Pisanie kodu:
Najważniejsza jest czytelność kodu. Pisany kod powinien być zrozumiały dla innych, nie tylko do piszącego.
Nie powtarzaj się, bez sensu jest pisać kod wykonujący tą samą funkcjonalność w kilku miejscach.
Pliki nie powinny być większe niż 500 wierszy, a wiersz nie powinien być dłuższy niż 120 znaków. Zapewni to większą czytelność kodu, bez potrzeby długiego przewijania pliku.
Używaj wcięć w kodzie: przy warunkach, zagnieżdżeniach czy pętlach.
Nazwy:
Nazwy metod powinny być czasownikami,
Nazwy zmiennych, klas i obiektów powinny być rzeczownikami,
Nazwy klas – zaczynane od dużej litery (np. Student),
Stałe - złożone tylko z dużych liter (np. MAX_VALUE),
Metody i zmienne zaczynają się małą literą, a nowe słowo z dużej bez podkreślników, myślników, innych odstępów w nazwie (np. returnOsoba),
Nazwy powinny mieć znaczenie,
Nazwy mogą być długie, nie używać niezrozumiałych skrótów,
Nazwy nie powinny być podobne do siebie,
Nazwy powinny odnosić się do rozwiązywanego problemu,
Nazwy powinny być możliwe do wymówienia,
Nie używać jednoliterowych zmiennych chyba ze jako licznik pętli (i,j,k)
Unikać słów kluczowych np. manager, procesor, info,
Używać set, get, is.
Metody:
Metody powinny być krótkie (max 20 wierszy),
Jak najmniej kodu w pętlach i warunkach (najlepiej jeden wiersz),
Metody nie powinny mieć wielu argumentów (najlepiej 0, max 3),
Metoda powinna wykonywać tylko jedno zadanie i nie mieć efektów ubocznych,
Metoda nie powinna robić czegoś co nie wynika jasno z jej nazwy,
Metody muszą być zrozumiałe,
Długą obsługę wyjątku lepiej przenieść do nowej metody,
Metody w klasie powinny być ułożone hierarchicznie. Bezpośrednio pod metodą wszystkie metody w niej wykorzystywane,
Metoda powinna korzystać tylko z metod udostępnionych przez:
- macierzysty obiekt,
- obiekty podane w argumentach,
- obiekty które sama stworzyła,
Komentarze:
Najlepszą formą komentarza jest sam kod. Lepiej gdy komentarzy jest jak najmniej, a jeżeli już wystąpił powinien być zwięzły. Komentarze mają tendencję do utraty aktualności, w miarę starzenia się kodu. Lepiej zmienić kod, tak aby był czytelniejszy niż komentować kod nieczytelny. Nie używać graficznych podziałów kodu np. /////////////////// filtr /////////
Nie zakomentowywać kodu – później nie wiadomo co on robił do czego służył i czy można go usunąć.
Zły komentarz to komentarz:
- opisujący oczywistość,
- nieaktualny,
- kłamliwy,
- który nic nie wnosi,
Gdzie można komentować:
- copyright u góry pliku,
- cel wykonania wydawałoby się bezsensownych akcji,
- wytłumaczenie użytych bibliotek,
- komentarze TODO – rzeczy do zrobienia w przyszłości (najlepiej żeby było ich jak najmniej i żeby szybko go usunąć).