Skróty | Skrótowce
Jest to bardzo prosta reguła, według której nie powinniśmy stosować żadnych (niemalże) skrótowców w naszym kodzie. Chodzi tutaj o skracanie wielu rzeczy, ale prawie za każdym razem skróty niosą za sobą szereg wad.
Klasy
Jeśli kiedykolwiek próbowałeś skracać nazwy klas, tworzyć jakieś skrótowce, z całą pewnością nic dobrego z tego nie wynikło. Dla przykładu nazwa klasy Trnsltr (zamiast Translator). Okropieństwo. Nigdy nie twórz takich nazw klas czy zmiennych. Ale dlaczego?
A dlaczego to taki problem zapisać pełną nazwę? Skąd ten pociąg w kierunku skracania? Jakby te kilka literek więcej miało nas zabić? A nie zabije i nie ma żadnego negatywnego znaczenia. A nawet zapisanie takiego skrócenia będzie wolniejsze.
Żadnych zalet, same wady. Zapisanie pełnej nazwy będzie szybsze i będzie działać dobrze na naszą pamięć. Kompletnie zero profitów ze stosowania tutaj skrócenia.
Zmienne
Wyobraź sobie pętlę foreach, w której masz zapisane foreach($x in $item)... Dla przykładu; mogłeś tutaj użyć na szybko byle zmiennej $x by przyspieszyć sobie pracę... Ale z czym tak naprawdę skończyłeś? W taki sposób tworzysz słabej jakości kod. Który do tego jest bardzo nieczytelny i niejasny. I nawet jeśli w małej ilości to nie jest groźne, to tendencja do robienia tego sprawi, że szybko będzie to rosło i rosło i przerodzi się w okropnie napisaną aplikację.
A gdzie tu jasność? Co pomyślisz patrząc na ten kod po dłuższym czasie? Albo co pomyślą inni? Czysta strata energii i czasu. Dodajesz tylko koszt. Zaciągniesz tylko dług technologiczny w niepotrzebny i głupi sposób.
Co więcej, warto wspomnieć, że współczesne narzędzia mają funkcję autouzupełniania. To też sprawia, że skracanie nie ma żadnego sensu.
Swoją drogą jedyna sytuacja w której powinieneś korzystać ze zmiennych nazwanych $x i $y, to gdybyś pracował ze współrzędnymi. Wtedy to ma sens 
.
Metody
Jako przykład może tutaj posłużyć metoda fetch($pesel). Jest to metoda, do pobierania osoby po jej numerze pesel. W czym problem? A no w użyciu. Albowiem w użyciu nie będziesz pamiętał, co musisz podać jako argument. Mógłbyś pomyśleć, że ID - ale nie, bo pesel...
Jakby nie patrzeć - fetch, jest również swego rodzaju skrótem. A co tak naprawdę tutaj robimy? Jak to moglibyśmy lepiej nazwać? Pobieramy użytkownika po jego numerze pesel. Więc może lepiej nazwać tę metodę fetchByPesel($pesel).
To prawda, mamy trochę dłuższą nazwę metody, trochę więcej liter i słów. Jednak zyskujemy dużo lepszą czytelność, jasność i oszczędność czasu i energii w przyszłości. Tworzymy lepsze API.
Niech nazwa metody prawdziwie opisuje to, co w niej się dzieje.
Zbyt długie nazwy
Jeśli potrzebujesz dużej ilości słów i liter by nazwać jakąś metodę, to może być poważny problem.
Uważaj na długie nazwy metod. Często mogą wskazać miejsce które potrzebuje refaktoryzacji. Miejsce w którym SRP jest pogwałcone.
Metoda w której robisz tak dużo, że próbujesz dopasować nazwę metody by opisać co się w niej dzieje. Może cię to nakierować właśnie na metodę do refaktoryzacji. Przykład: prepAndSendAndAccessDBAndFireEvent()... Masakra .
Nazwy zmiennych to samo. Znajdź odpowiednie słowa, bądź lapidarny .
Zbyt ogólne nazwy
Uważaj na zbyt ogólne nazwy. Dla przykładu nazwa metody process(). Co z nią nie tak? W większości przypadków w żaden sposób nie opisuje ani nie mówi o tym, co się w niej właściwie dzieje.
Tak samo ze zmiennymi. Niech nazwy naprawdę mówią co się w nich znajduje. Nie bądź ogólny, bądź konkretny! Jednak również nie przesadź .
Zbyt konkretne nazwy
Nie raz nazwy mogą być zbyt konkretne. Dla przykładu metoda hireUser() w klasie User. Jaki tym razem problem? Choć przy kodowaniu klasy może się wydawać okej, to spójrz na użycie... $user->hireUser();. Widzisz tutaj redundancję? Przy pisaniu metody może wyglądało to okej, ale w użyciu już nie... Tutaj problemem więc nie jest skrócenie, lecz bycie zbyt konkretnym . Lepszą nazwą metody byłoby tutaj samo hire().
Staraj się projektować najpierw zaczynając od użycia. Niesie to za sobą wiele zalet . Często stosuje się to np. przy podejściu TDD. Gdzie najpierw myślisz jakbyś używał wszystkiego zanim to zbudujesz.
Wyjątki
Czasami skróty są okej. Ale to tylko wyjątki. Przypadkiem jest tutaj ID. Dlaczego? Ponieważ jest to skrót tak szeroko znany i powszechnie używany, że nie ma kompletnie żadnej korzyści z pisania Identifier zamiast ID.
Podsumowanie
Nie skracaj. Dbaj o API. Sprawdzaj jak to wszystko wygląda w praktyce. Pamiętaj, że czytelność, jasność, oczywistość, prostota czy przejrzystość to niezwykle ważne cechy dobrego i porządnego kodu. Dbaj o to !
Kończąc
Dziękuję ci za lekturę, proszę podziel się swoją opinią w komentarzu oraz udostępnij ten artykuł jeśli był dla ciebie pomocny . Zapraszam cię również do lektury innych moich artykułów.
A tymczasem życzę ci dobrego dnia, bywaj !