Odpowiednie dać rzeczy słowo

Archived under Programming on February 26th, 2005 with 3 comments

… czyli o konwencjach nazewniczych. Niedawno u Mimasa pojawił się przykład radosnej twórczości w tej dziedzienie:

pobierzListaPismDoWydruku()
getListaOdwolanDlaRaport()
dajListeOdwolanDoRaportu()
wycieczka do piekła

Skoro tak nie należy pisać, więc jak powinno się to robić?

Na pewno mniej problemów mają Anglosasi — nazwy zmiennych, tabel w bazie danych czy treść komentarzy mogą pisać w ojczystym języku, a kod nie będzie nasuwał skojarzeń z wieżą Babel.

Ponieważ składnia języków programowania, których używamy na co dzień, bazuje na angielskim, więc od zawsze piszę wszystko właśnie za jego pomocą: od zmiennych począwszy, na komentarzach skończywszy. Może to ślady snów o potędze i marzeń o opublikowaniu kodu Fleksa, a może po prostu kwestia gustu. Skoro wszystkie wbudowane elementy składni języka są zaczerpnięte z angielszczyzny, więc wolę unikać zbędnego zamieszania.

Na niekorzyść naszego rodzimego języka wpływają też znaki diakrytyczne. O ile w komentarzach można sobie na nie pozwolić, to już w nazwach zmiennych mogą sprawiać problemy. I pewnie sprawiają — nigdy nie odważyłem się na taki eksperyment. Zamiast polskawej (bez ogonków) odmiany naszego języka, wolę już swój łamany angielski.

Gdy domyślnym językiem aplikacji jest angielski, ewentualnie jest ona, jak Flex, przygotowana z myślą o pracy z paczkami językowymi, wybór jest oczywisty. A co w wypadku rzeczy projektowanych wyłącznie z myślą o rodzimym odbiorcy, np. serwisie internetowym?

Załóżmy, że za pośrednictwem strony naszej Firmy prowadzimy sprzedaż Produktu oraz Usługi. URL-e powinny być przyjazne, a zatem link prowadzący do podstrony umożliwiającej zakup odmiany Produktu o identyfikatorze 123 mógłby wyglądać np. tak:

http://www.firma.pl/sklep/produkt/123/

Uważam, że przyjazny adres powinien jak najwiecej mówić użytkownikowi i mieć logiczną budowę. Najlepiej jest, by parametry były zrozumiałe i pozwalały się łatwo odcyfrować. Dlatego jestem przeciwnikiem angielskich słów w rodzaju action, mode czy page w adresach stron adresowanych do rodzimego odbiorcy. (Gwoli wyjaśnienia: strukturę adresów na tej stronie wymyślałem, gdy miałem na to inny pogląd. Również rodzimy język adresatów bloga miał być nieco inny).

Skoro więc do naszej aplikacji na serwerze trafiają parametry o polskich nazwach, jak nazywać zmienne i funkcje? Albo jakie nazwy wybrać dla tabel w bazie danych: produkty i uslugi czy products i services?

Pierwszą i najważniejszą zasadą towarzyszącą wyborowi nazw w obrębie kodu powinna być konsekwencja. W tym wypadku jesteśmy skazani na kompromis. Załóżmy, że zdecydujemy się na polskie nazwy. Tworzymy klasę tabelę o nazwie produkty i klasę ProduktJak nazwać metodę klasy, która pobiera informacje o produkcie? pobierzDaneProduktu() (bo polsku i w zgodzie z przyjętą konwencją), a może getDaneProduktu() (bo nazwę metody pobierającej informacje uświęcona tradycja każe rozpoczynać, bynajmniej nie polskim, słówkiem get)? Idąc dalej, dochodzimy do polskawej nazwy metody pobierzDaneUslugi(). W miarę rozrostu projektu spotykamy coraz więcej podobnych dylematów.

Dokładnie ten problem miałem ostatnio, podczas pracy nad pewnym sporym serwisem. Zacząłem od polskich nazw elementów, ale szybko mnożyły się potworki podobne do pokazanych wyżej. Jeśli ktoś się jeszcze nie zorientował, to donoszę, że jestem purystą językowym i zdecydowałem się w końcu na radykalne rozwiązanie. Wszystkie polskie nazwy zastąpiłem w kodzie ich angielskimi odpowiednikami.

W praktyce oznacza to, że parametr przekazany do skryptu w adresie jest po polsku (czy raczej polskawu, bo bez ogonków), ale w tym skrypcie cała reszta jest już po angielsku. Przykładowy kod w PHP mógłby więc wyglądać np. tak:

if ($_GET['typ'] == 'usluga') {
    $details = $service->getDetails($id);
}

Nieco bardziej eleganckim rozwiązaniem byłoby odwzorowanie polskich nazw na ich angielskie odpowiedniki:

if ($_GET['typ'] == 'usluga') {
    $type = 'service';
}

(Od razu uwaga: aby uzyskać naprawdę przyjazne URL-e trzeba zrezygnować z wygodnej tablicy $_GET i posłużyć się nieco bardziej wyszukanymi metodami. Po szczegóły odsyłam do artykułu na php.pl.)

Dzięki umieszczeniu czegoś takiego w jednym miejscu skryptu (np. w jakiejś metodzie), dalej możnaby już konsekwentnie posługiwać się słowami z ojczystego języka Britney Spears:

if ($type == 'service') {
   $details = $service->getDetails($id);
}

Wracając do przykładu z historii Mimasa, pewnie byłbym za nazwaniem metody getReportReferencesList(), nawet gdyby w menu użytkownika figurowała Lista odwołań do raportu.

Ciekaw jestem, jak radzą sobie z tym inni — czekam na komentarze :).

Comments

  1. Od pół roku – wyłącznie po angielsku. Adresy, jeśli mają być ładne, to i tak parsuję niezależnie w jakimś wrapperze, budując na ich podstawie angielskie zmienne. Tak, też jestem purystą językowym. :o)

    Shot

  2. Raczej angielski nazwy, choć czasami zdarzają się zaniki ‘intelektualne’ i różnie to wychodzi :), szczególnie w C/C++, jeśli chodzi o geta, to oczywiście zamiana na polskie odpowiedniki.

    macem

  3. Ależ, ależ! Przecież aplikację można pisać w całości w języku Szekspira, a adresy przykryć na koniec. To podejście wydaje mi się aktualnie najbardziej rozwojowe.

    Cezary Okupski

Comments are now closed