Czy sensowne jest używanie „ys” zamiast „ies” w identyfikatorach, aby ułatwić wyszukiwanie i zamianę? [Zamknięte]

Chociaż gramatycznie niepoprawne, pisząc identyfikatory funkcji, zmiennych itp., Warto po prostu dodać „s” do liczby mnogiej słów kończących się na Y? Moim powodem jest to, że jeśli potrzebujesz znaleźć i zastąpić, na przykład, zastępując „firma” słowem „sprzedawca”, „firma” pasowałaby zarówno do formy pojedynczej, jak i mnogiej („ firma i” firma ”), podczas gdy jeśli liczba mnoga została zapisana poprawnie, należy wykonać dwa osobne wyszukiwania.

Każde takie wyszukiwanie i zamiana powinny być wykonywane ostrożnie, a każda zmiana ręcznie sprawdzana, aby np. Uniknąć „towarzyszenia” w komentarzu, stając się „acvendor” wraz ze zmianą firmy / dostawcy. W związku z tym dwa oddzielne wyszukiwania wyrażeń „firma” i „firmy” nie powinny powodować znacznych kosztów ogólnych w porównaniu z czasem poświęconym na sprawdzanie i zatwierdzanie każdej zmiany.

Tak więc błędy pisowni w celu osiągnięcia tylko jednego wyszukiwania mają negatywne strony, które wyglądają źle i są trudniejsze do odczytania niż to konieczne, bez żadnych oczywistych korzyści.

Zakładam, że mówisz o zmianie nazwy w plikach kodu źródłowego. W przypadku dzisiejszych IDE zawsze powinno się to odbywać za pomocą narzędzi refaktoryzujących IDE. Jeśli twoje IDE tego nie ma, rozważ przejście na inne IDE. Większość narzędzi refaktoryzujących IDE również przechowuje historię refaktoryzacji, co daje możliwość szybkiego „cofnięcia”, jeśli nie podobają Ci się wyniki refaktora. Korzystając z wyszukiwania / zamiany, możesz nie mieć możliwości cofnięcia całego zestawu zmian (chyba że możesz użyć narzędzi kontroli wersji i powrócić do poprzednio zatwierdzonej wersji). Ponadto, korzystając z narzędzi refaktoryzacyjnych, jesteś bezpieczniejszy od przypadkowej zmiany czegoś, czego nie zamierzałeś zmienić.

Tak! Tak! Tak! Ma to sens. I robię to od lat.

Ujawnienie 1: Angielski nie jest moim językiem ojczystym.

Ujawnienie 2: Moja znajomość gramatyki języka angielskiego jest znacznie lepsza niż przeciętnego native speakera.

Ujawnienie 3: Jeśli chodzi o komunikację z ludźmi, jestem gwałtowną gramatyką nazistowską.

A teraz, gdy ujawnienia te są już na uboczu, pozwólcie, że stwierdzę, że w gramatyce angielskiej nie ma miejsca w kodzie. Widzisz, dlatego nazywa się to kodem, a nie prozą . Ma on przypominać język rozumiany przez ludzi w celu czytelności, ale poza tym, czego najbardziej potrzebujemy od kodu, nie są cechy prozy; to inne, bardziej techniczne cechy, takie jak precyzja , jednoznaczność i zwięzłość . Dlatego składnia C if( x != y ) y++;jest o wiele lepsza niż IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF.składnia Cobola. Rzekoma celowość kompilatorów, które rozumieją język naturalny, jest błędem i nie wierz mi na słowo, zobacz, co ol'Edsger ma do powiedzenia na ten temat:Edsger W. Dijkstra, O głupocie „programowania w języku naturalnym” .

Kolejną ważną cechą jest możliwość obliczania identyfikatorów . Fakt, że wywoływana właściwość Colorzawsze może być odczytana za pomocą metody wywoływanej getColor()i zapisywanej za pomocą metody nazywanej, setColor()ma ogromne znaczenie. Te identyfikatory są obliczalne na podstawie nazwy nieruchomości, więc nie musisz ich znać na pamięć. Gdyby programista wybrał parę metod wywoływanych getColor()z jednej strony, ale colorize()z drugiej strony, ich koledzy słusznie rozważyliby ten sabotaż. Tak ważna jest obliczalność identyfikatora.

Można także napisać narzędzia programistyczne (a napisano ich wiele, na przykład Hibernacja ), które potrafią obliczyć te nazwy. Bez możliwości obliczenia nazwy identyfikatora musiałbyś zastosować dodatkową składnię (np. W Hibernacji, dodatkowe adnotacje), aby dokładnie określić dla każdego narzędzia, jak utworzyć każdą nazwę identyfikatora lub dokładnie, jaką nazwę ad hoc nadałeś każdej jednostce.

Tak więc obliczalność identyfikatora jest ważna, a jednocześnie gramatyka angielska jest nieistotna (ponieważ nie zajmujemy się programowaniem w języku naturalnym), aby móc obliczyć nazwę zbioru bytów, zawsze dodając „s” do nazwy pojedynczego wystąpienia ma doskonały sens, nie wspominając o tym, że narusza wrażliwość większości ludzi (w tym mojej) na język angielski.

I czy nam się to podoba, czy nie, to trend przyszłości. Językiem ojczystym większości programistów na naszej planecie nie jest już angielski, a trend jest bardzo silny w tym kierunku. (Nie chciałbym nawet postawić pieniędzy na sugestię, że angielski jest językiem ojczystym większości programistów pracujących obecnie w USA.) Są to ludzie, którzy w dużej mierze próbują obliczyć nazwę kolekcji z nazwą pojedynczego wystąpienia „firma”, po prostu doda „s”, a forma „firmy” nawet nie przyszło im do głowy. Dla ogromnego i wciąż rosnącego odsetka programistów na świecie znajomość specyfiki języka angielskiego nie wnosi żadnej wartości do ich pracy, a jedynie czyni ją nieco trudniejszą.