Dobra nazwa nie jest zła
Wraz ze wzrostem doświadczenia, coraz większą uwagę przykładam do nazw w kodzie. Pomimo że nazwy dla kompilatora to tylko unikalne identyfikatory adresów. Jednak u ludzi sprawa wygląda zgoła odwrotnie. Gdyby zabrano nam możliwość nadawania nazw, nie bylibyśmy w stanie tworzyć nawet prostych programów. Niejednokrotnie dobra nazwa jest ważniejsza niż kod, który znajduje się pod spodem. Dlaczego dobra nazwa w kodzie nie jest zła?
Zła nazwa jest zła
Rozróżniam trzy kategorie niepoprawnych nazw. Wszystkie spoczywają na takim samym kamieniu węgielnym, jakim jest niezrozumienie. Jednak ich geneza i zamieszanie, jakie wprowadzają to zupełnie inne poziomy.
Deweloperska na brudno
Nazwa tego typu powstaje w czasie procesu wytwarzania oprogramowania. Gdy programiście brakuje czasu, by zastanowić się, jak nazwać tworzony kod. Powstaje jako tymczasowa, z planem poprawy, na wolną chwilę. Przykładem takiej nazwy może być 'aaa', 'temp', czy najpopularniejsza 'dupa'. Mimo swoich wad najmniej szkodzi, bo nie wprowadza w błąd, ani nie pozostawia złudnej nadziei jak pozostałe.
Zbyt ogólna
Czasem można spotkać klasy-worki, niepozwalające określić swojej odpowiedzialności. Kod w nich robi wszystko, ale nic konkretnego. Rosną do niebotycznych rozmiarów. Ich pęcznienie powoduje dodatnie sprzężenie zwrotne. Im bardziej ich odpowiedzialność jest rozmyta, tym więcej rzeczy tam wpada, które z kolei rozmywają ją jeszcze bardziej. Weźmy na ruszt klasę CommonHelper, czy UserManager. Już po samej nazwie wiemy, że w środku jest takie „nie wiadomo co”. Jeżeli spotkasz coś takiego i zastanawiasz się jak to ogarnąć to zapraszam do posta o tym jak refaktorować.
Kłamliwa
Najgorsze wcielenie złej nazwy. W powyższych przykładach przynajmniej widać, że coś jest nie tak. Tutaj żyjesz w błogiej nieświadomości, dopóki nie wejdziesz w głąb. Weźmy klasę UserValidator. Na pierwszy rzut oka odpowiada za walidację użytkownika. Świetnie!. A w środku skrywa się kod odpowiedzialny przykładowo za składanie zamówienia? Gdzie sens, gdzie logika? Takie twory nie powstają od razu. One ewoluują latami, wystawione na promieniowanie ignorancji i niezrozumienia.
Kilka punktów o nazwach w kodzie
Na koniec jeszcze krótkie podsumowanie/rozwinięcie w formie listy.
- Dobra nazwa powinna opisywać co dana klasa robi, a nie w jaki sposób.
- Dobrze dobrana nazwa pozwala na prawie całkowite pozbycie się komentarzy w kodzie.
- Poprzez dobrą nazwę wchodzimy na wyższy stopień abstrakcji.
- Jeśli mamy zaufanie do naszych nazw to kodowanie staje się przyjemniejsze.
- Najgorsza rzecz, jaka może nam się trafić to utrata zaufania do nazw.
Koniec
To z pewnością nie wszystkie rodzaje niepoprawnych nazw. Jednak te najważniejsze. Czy zgadzasz się z moimi punktami? A może jest jeszcze jakiś ważny typ przeze mnie pominięty?
0 Komentarzy