W poprzednim wpisie omówiłem, krótko, bo krótko, problem skracania nazw w kodzie. Dziś poruszę problem zbyt długich nazw. One też nie są dobre.
Co oznacza „nazwa opisowa”?
No właśnie… Czy pojęcie to oznacza nazwę, która jest długa, precyzyjna i w najmniejszych szczegółach oddająca co dzieje się w środku? A może nazwa opisowa niesie ze sobą pewien „ładunek emocjonalny”, który pozwala na wczucie się w kod? Był sobie taki nurt w literaturze. co nazywał się RealizmW. Jednym z jego najwybitniejszych przedstawicieli był Lew TołstojW. I większość z nas zapamiętała go jako autora długich, bardzo szczegółowych opisów.
Obserwacja
Im bliżej technicznych aspektów projektu, tym bardziej rozwlekłe są nazwy. Jest to oczywiste przeciwieństwo problemu z poprzedniego wpisu. Być może ma ono źródło w „nie jesteśmy humanistami” i brakach w umiejętnościach językowych? Z drugiej strony płodzenie takich potworków.
Podsumowanie
Na dziś tyle. Zostawiam was z problemem nazywania różnych elementów w kodzie i szukania tego złotego środka pomiędzy nazwami zbyt krótkimi i zbyt długimi. Jako „zadanie domowe” możecie spróbować wypisać sobie trzy dobre i trzy złe cechy nazw popularnych algorytmów jak Quick Sort, A*, Sidewinder.
Zauważyłem, że często zbyt skomplikowane nazwy świadczą o tym, że kontekst nie został rozdzielony. Wielokrotnie programista woli dopisać metodę w istniejącej klasie z bardziej skomplikowaną nazwą niż stworzyć zupełnie nową klasę(z bardziej specyficzna odpowiedzialnością) za którą będzie się czuł odpowiedzialny.