Istnieje zalecenie, aby tworząc terminologię opierać ją na już istniejącej czy to w danym języku i jego bibliotekach, czy też w samym projekcie. Nazywając klasy, które implementują jakiś wzorzec należy w ich nazwach używać nazwy tegoż wzorca, bo to pozwoli czytającemu gładko zinterpretować przeznaczenie klasy. Trudno się z tym zaleceniem nie zgodzić, jest ono oczywiste wręcz na poziomie podświadomości.

Jak to jednak z zaleceniami bywa, w teorii wyglądają one przepięknie, kiedy jednak człowiek przechodzi do praktyki, ze szczególnych przypadków zaczyna wyłazić diabeł ;). Weźmy choćby pod uwagę bibliotekę .NET Framework. Chcąc swoją terminologię opierać na niej trzeba… znać ją w dużym zakresie. Choć – z drugiej strony – przecież powinna być ona spójna znaczeniowo (w końcu programiści MicroSoft też stosują zalecenia i zasady), więc jeśli jako tako się ją pozna, można śmiało założyć, że jej nieznane obszary będą nomenklaturowo podobne do tych już znanych.

Czy zatem możemy już zanucić „oj dana, dana nie ma szatana!” ;). Jeszcze nie! Bo do tego dochodzi jeszcze intencja tworzących terminologię. Ostatnio rozpatrywałem przypadek pustego łańcucha (string) tj.: czy zmienną łańcuchową, która jest równa null należy traktować jakoś inaczej niż taką, w której brak treści? Czy jeżeli chcę się dowiedzieć, czy mam w zmiennej treść, to muszę rozgraniczać fakt, że owszem nie mam, bo ona po prostu nie wskazuje na nic, od faktu, że rzeczywiście nie przechowuje treści (przechowuje pustą treść)? Z punktu widzenia końcowego efektu nie ma to znaczenia. Zatem metoda, która powinna sprawdzać czy zmienna łańcuchowa nie przechowuje treści mogłaby się nazywać po prostu Empty(). Niestety, zaglądając do klasy String dostrzegam istniejąca już tam metodę, która nazywa się NullOrEmpty() i robi dokładnie to samo, tylko że pojęciowo rozgranicza te dwa stany zmiennej łańcuchowej. Chcąc być w zgodzie z omawianym zaleceniem, nie mogę sprowadzić do tego samego znaczenia, czegoś co .NET rozgranicza, bo inny programista traktujący pojęcie Empty zgodnie z filozofią biblioteki .NET, moją metodę intuicyjnie źle zinterpretuje. Pozostaje mi poszukać synonimu. Pierwsza myśl to NoContents(), ale to kłóci się z zaleceniem unikania warunków negatywnych (chcąc się dowiedzieć czy jest jakaś zawartość musiałbym podwójnie negować: raz w nazwie drugi raz w samy warunku – (if (!NoContents())…). Zatem pozostaje mi ContentsExists(), co niestety jest długie lub Blank(), co znowu nie jest tak popularne, zatem i oczywiste. Czego bym jednak nie wybrał, to co wydawało mi się najbardziej czytelne – pozostanie poza moim zasięgiem.

Koniec końców zweryfikowawszy prostotę (hm, prymitywność 😉 ) swojego pojmowania łańcucha i nazywam metodę dokładnie tak samo: NullOrEmpty(). Skoro w świecie .NET jest to istotne, nie powinienem udawać, że istotne jednak nie jest – czytelność przede wszystkim :).