fbpx

Dobra nazwa nie jest zła

Opublikowane przez Jerzy Wickowski w dniu

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 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 „niewiadomoco”. 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

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?



Czy to był wartościowy artykuł? Bądź na bierząco. Zapisz się, a poinformuję Cię o nowych postach

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Zapisz się

Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.