(Prawie) cała prawda o nazywaniu metod

Mówi się, że dwie najtrudniejsze rzeczy w programowaniu to: wygaszanie cache i dobieranie nazw. Trochę w tym prawdy. Są nawet tacy, którzy przyznają, że cache to jeszcze, ale te nazwy…

Jakie powinny być nazwy?

No właśnie, jakie powinny być nazwy i co powinny mówić? Powinny mówić całą prawdę i tylko prawdę o tym, co dana metoda robi. Nie piszesz kodu dla siebie, tylko dla innych (i siebie w przyszłości). Nawet wujek Bob mówi o tym w Czystym Kodzie, że proporcje czytania kodu do pisania to 10 do 1. Jeśli metoda zwraca cenę produktu powiększoną o VAT, to wolisz, żeby się nazywała getPrice czy getGrossPrice? Ja wolę tę drugą!

Jest jeszcze jedno ciekawe zagadnienie dotyczące nazw. Jeśli nazwa mówi o wszystkim co robi metoda, to jeśli nazwa staje się zbyt długa i zagmatwana, to co to oznacza? No właśnie, że metoda też taka jest i należy ją rozbić, albo zmniejszyć jej zakres działania. Podobnie jest z testami. Jestem wielką fanką długich i szczegółowych nazw testów. Jeśli ta nazwa nie mieści się już w linii, to coś chyba poszło nie tak. Wtedy można zrobić krok wstecz i zastanowić się, co tak naprawdę chcesz testować?

A nazwy metod testowych?

Nie wiem jak Ty, ale ja rzadko czytam raport testów, jeśli wszystko jest zielone. Nazwy testów przydają mi się wyłącznie w dwóch sytuacjach. Pierwsza to przygotowania do implementacji nowej funkcjonalności. Przeważnie zaczynam swoje oględziny od testów i sprawdzam, co się w tej części projektu dzieje, jakie są zasady gry. Druga to „wysypany” test. Jeśli test jest wyświetlony na czerwono w konsoli, albo IDE, jego nazwa staje się interesująca. Najlepiej, kiedy nazwa jest tak dobra, że nie trzeba nawet otwierać klasy testowej. W JUnit5 wprowadzono adnotację @DisplayName, która jeszcze bardziej ułatwia czytanie nazw testów.

Nazwa testu nie ma znaczenia, bo w raporcie jest wyświetlane piękne zdanie ze spacjami.

Oczywiście my już doszliśmy do wprawy w czytaniu CamelCase’ów, czy innych_snake’ów. Jednak reszta świata ciągle używa białych znaków. W dodatku całkiem spójnie, najczęściej są to pojedyncze spacje. Jeśli traktuje się raport testowy jako dokumentację, ta forma może być zdecydowanie bardziej przyjazna dla nietechnicznych uczestników przygody rozwoju oprogramowania.