Czy warto używać symboli Unicode jako identyfikatorów Java?

Question

Mam fragment kodu, który wygląda tak:

double Δt = lastPollTime - pollTime; 
double α = 1 - Math.exp(-Δt/τ); 
average += α * (x - average); 

Podobnie jak zły pomysł, to go do używania znaków Unicode w identyfikatorach Java? Czy jest to całkowicie dopuszczalne?

Answer 1

To zły pomysł, z różnych powodów.

• Klawiatury wielu osób nie obsługują tych znaków. Gdybym miał zachować ten kod na klawiaturze qwerty (lub jakiejkolwiek innej bez greckich liter), musiałbym cały czas kopiować i wklejać te znaki.

• Niektóre edytory lub terminale niektórych osób mogą nie wyświetlać poprawnie tych znaków. Na przykład niektórzy edytorzy (niestety) nadal domyślnie wybierają jakiś wariant ISO-8859 (łaciński). Głównym powodem, dla którego ASCII jest tak powszechne, jest fakt, że prawie zawsze działa.

• Nawet jeśli znaki mogą być renderowane poprawnie, mogą powodować zamieszanie. Straight from Sun (Kopalnia nacisk):

  Identyfikatory, które mają taki sam wygląd zewnętrzny może być jeszcze inaczej. Na przykład identyfikatory składające się z pojedynczych liter LATIN CAPITAL LIST A (A, \ u0041), LATIN MAŁY LIST A (a, \ u0061), GREEK LITERA KAPITAŁOWEGO ALPHA (A, \ u0391), CYRILICZNEGO MAŁEGO LITERA A (a , \ u0430) i MATHEMATICAL BOLD ITALIC SMALL A (a, \ ud835 \ udc82) są różne.

  ...

  znaków Unicode kompozytowe są różne od rozkładających znaków. Na przykład, LATYNOWY LITER KAPITAŁOWY OSTRY (Á, \ u00c1) może być uważany za taki sam jak LATYNOWY LITER KAPITAŁOWY A (A, \ u0041), po którym bezpośrednio następuje NIEAKTUALNA ODPOWIEDŹ (", \ u0301), gdy sortowanie, ale są one różne w identyfikatorach.

  ta nie jest w żaden sposób wyimaginowanej problem: a (U + 03b1 GRECKI małej litery alfa) i ⍺ (U + 237a APL funkcjonalny SYMBOL alfa) są różne postacie!

• Nie można określić, które znaki są poprawne. Znaki z twojego kodu działają, ale kiedy używam FUNCTIONAL SYMBOL ALPHA, mój kompilator Javy narzeka na "nielegalny znak: \ 9082". Mimo że symbol funkcjonalny byłby bardziej odpowiedni w tym kodzie. Wydaje się, że nie ma solidnej reguły określającej, które znaki są akceptowalne, za wyjątkiem askingCharacter.isJavaIdentifierPart().

• Mimo że można go skompilować, wątpliwe jest, aby wszystkie implementacje maszyn wirtualnych Java były rygorystycznie testowane przy użyciu identyfikatorów Unicode. Jeśli te znaki są używane tylko dla zmiennych w zakresie metody, powinny zostać skompilowane, ale jeśli są to członkowie klasy, to również znajdą się w pliku .class, prawdopodobnie powodując przerwanie programu w implementacjach JVM o błędach.

Answer 2

Dlaczego nie? Jeśli osoby pracujące nad tym kodem mogą łatwo je wpisać, jest to dopuszczalne.

Ale bóg pomaga tym, którzy nie mogą wyświetlić Unicode, lub którzy nie mogą ich wpisać.

Answer 3

wygląda dobrze, ponieważ używa prawidłowych symboli, ale ile osób z zespołu będzie znało naciskanie klawiszy na te symbole?

Chciałbym użyć reprezentacji angielskiej tylko po to, aby ułatwić pisanie. Inni mogą nie mieć zestawu znaków, który obsługuje te symbole ustawione na ich komputerze.

Answer 4

Ten kod jest w porządku, aby czytać, ale straszne do utrzymania - Proponuję używać Plain English identyfikatory tak:

double deltaTime = lastPollTime - pollTime; 
double alpha = 1 - Math.exp(-delta.... 

Answer 5

Jest to całkowicie dopuszczalne, jeśli jest to dopuszczalne w grupie roboczej. Wiele odpowiedzi tutaj opiera się na aroganckim założeniu, że każdy programuje po angielsku. Programiści, którzy nie są Anglikami, wcale nie są rzadkością i stają się coraz rzadsi w coraz szybszym tempie. Dlaczego mieliby ograniczać się do wersji angielskich, skoro mają do dyspozycji doskonale dobry język?

Oprócz arogancji z boku, istnieją inne uzasadnione powody używania nieanglojęzycznych identyfikatorów. Jeśli piszesz pakiety matematyczne, na przykład, używanie greki jest w porządku, jeśli twoim celem są inni matematycy. Dlaczego ludzie powinni wypisać "delta" w grupie roboczej, kiedy wszyscy rozumieją "Δ" i prawdopodobnie szybciej to wypiszą? Prawie każda domena problemowa będzie miała własny żargon, a czasem żargon ten będzie wyrażany w czymś innym niż alfabet łaciński. Dlaczego, na Boga, chciałbyś spróbować zaszyfrować wszystko w ASCII?

Answer 6

To doskonały pomysł. Szczery. To po prostu nie jest łatwe w praktyce w czasie. Zachowajmy odniesienie do niej na przyszłość. Chciałbym miłość, aby zobaczyć trójkąty, koła, kwadraty, itp ... jako część kodu programu. Ale teraz, spróbujcie napisać to ponownie, tak jak sugeruje Crozin.

Answer 7

W idealnym świecie byłby to zalecany sposób.

Niestety, podczas kodowania znaków wykraczasz poza zwykłe 7-bitowe znaki ASCII (UTF-8 różni się od ISO-Latin-1 różni się od UTF-16 itd.), Co oznacza, że ​​w końcu napotkasz problemy. Zdarzyło mi się to podczas przechodzenia z systemu Windows na system Linux. Nasze narodowe skandynawskie postacie zepsuły się, ale na szczęście były tylko w strunach. Następnie użyliśmy kodowania \ u dla wszystkich tych.

Jeśli możesz być absolutnie pewien, że nigdy, przenigdy nie natkniesz się na coś takiego - na przykład, jeśli twoje pliki zawierają właściwą LM-a, to zrób to. Uczyni twój kod bardziej czytelnym. Jeśli przynajmniej najmniejsza wątpliwość, nie rób tego.

(Należy pamiętać, że "używaj języków innych niż angielski" to inna sprawa, po prostu myślę o używaniu symboli zamiast liter).