Jestem zwolennikiem terminologii angielskiej, czyli wszystkie identyfikatory w kodzie są w tym właśnie języku. Dzięki temu kod rzeczywiście jest samodokumentujący się, bo nie dławi go dysonans angielskiej składni i polskiej terminologii, który nieodwołalnie prowadzi do identyfikatorów typu „ponglish„, np. BeforeZapisz, RestoreZasoby. Oczywiście oddzielnym tematem jest jakość takiej terminologii (np. ewidencja dokumentów, to wszak nie DocumentEvidence 😉 ), niemniej – nawet jeśli ta kuleje – to da się ją w miarę sprawnie naprawić (narzędziami refaktoryzującymi), jak i zadbać o jej jakość (dając po prostu programiście już gotowe nazwy, których ma użyć oraz posiadając odpowiednie konwencje nazewnicze, których powinien się trzymać ustalając nazwy identyfikatorów).

O ile jednak kod taki czyta się bardzo sprawnie, o tyle prowadzenie na jego temat dyskusji zaczyna wyglądać kuriozalnie. Ta bowiem prowadzona jest w języku polskim (zakładam, że zespół nie jest międzynarodowy) i co chwila pojawiają się w niej angielskie słowa. Co gorsza są one spolszczane, bo chociażby odmiany przez przypadki wymaga od nas język polski. Dlatego tworzymy kustomersów i ci kastomersi (tak, tak, każdy inaczej to wymawia) są potem gdzieś przekazywani, aby jakąś operację na owych kastomerach (a co, przecież powinno się tworzyć liczbę mnogą, od liczby pojedynczej oryginału, a nie jego liczby mnogiej) przeprowadzić. No i powstaje nowomowa, która z boku brzmi jak bełkot, a i prowadzącym rozmowę nastręcza trudności interpretacyjnych. Bo: detekujemy czy resoursy egzists czy nie egzists, żeby móc je zasejwić w storydżu.

Trudno na ten stan cokolwiek poradzić, bo występuje tu efekt znany z popularnego doświadczenia, w którym przed czytającym stawiane jest zadanie nazwania koloru czcionek słowa, które jest nazwą zupełnie innego koloru – nie ma zmiłuj – człowiek czyta słowo zamiast określić rzeczywisty kolor (spróbujcie: czerwony, zielony, niebieski).

Osobiście staram się jednak – mimo wszystko – na bieżąco tłumaczyć omawiane terminy, od czasu do czasu dodając („czyli” i tu nazwę oryginalną z kodu). Nie jest to jednak proste zadanie, można się nieźle zmęczyć, niemniej mimo wszystko pozwala mi to lepiej trzymać wątek. Wszystko zależy od treningu ;). Często w ramach tego treningu specjalnie w rozmowie – pomimo, że rozmówca używa angielskiego terminu – zastępuję go polskim odpowiednikiem (zamiast hot-fix mówię po prostu poprawka, zamiast upgrade – ulepszenie lub aktualizacja).

Na koniec warto zwrócić uwagę, że w literaturze traktującej o czystości kodu i jego czytelności tego typu rozważania się nie pojawiają? Dlaczego? Ano dlatego, że zazwyczaj jest to literatura pisana przez anglojęzycznych autorów, dla których ten problem po prostu nie istnieje! Oni w tym języku, w którym piszą również prowadzą o nim dyskusje. Dopiero kiedy propagowane przez nich zalecenia zaczyna stosować cudzoziemiec, pojawia się ów dodatkowy aspekt (nie)czytelności. Paradoksalnie zatem nawet najbardziej czytelny kod z punktu widzenia posługującego się natywnym angielskim nie będzie tak czytelny dla cudzoziemca, bo tam zawsze będzie musiało następować tłumaczenie.

Mając na uwadze ten fakt warto jeszcze zwrócić uwagę, że piętnowanie komentowania klas, których sama nazwa powinna mówić o co chodzi (więc po co komentarz), w przypadku komentowania w innym języku, zaczyna mieć sens. Taki komentarz będzie po prostu jednoznacznym wskazaniem, jak dany byt należy interpretować. Dzięki temu owe – przywołane tu w ramach przykładu – DocumentEvidence, opatrzone komentarzem Ewidencja dokumentów pozwoli zmienić nazwę na poprawną. Ułatwi także rozmowę o terminach po polsku, bo InteliSense podpowie polski odpowiednik.