Действительно ли это - хорошая идея использовать unicode символы в качестве идентификаторов Java?
У меня есть отрывок кода, который похож на это:
double Δt = lastPollTime - pollTime;
double α = 1 - Math.exp(-Δt / τ);
average += α * (x - average);
Как плохо идея - это для использования unicode символов в идентификаторах Java? Или действительно ли это совершенно приемлемо?
7 ответов
Это плохая идея, по разным причинам.
Клавиатуры многих людей не поддерживают эти символы. Если бы я поддерживал этот код на клавиатуре qwerty (или любой другой без греческих букв), мне пришлось бы постоянно копировать и вставлять эти символы.
Некоторые редакторы или терминалы могут не отображать эти символы должным образом. Например, некоторые редакторы (к сожалению) все еще используют по умолчанию какой-либо вариант ISO-8859 (латиница). Основная причина, по которой ASCII все еще так распространен, заключается в том, что он почти всегда работает.
Даже если символы могут быть отображены правильно, они могут вызвать путаницу. Прямо из Sun (выделено мной):
Идентификаторы, имеющие одинаковый внешний вид, могут быть разными. Например, идентификаторы, состоящие из отдельных букв LATIN CAPITAL LETTER A (A, \u0041), LATIN SMALL LETTER A (a, \u0061), GREEK CAPITAL LETTER ALPHA (A, \u0391), CYRILLIC SMALL LETTER A (a, \u0430) и MATHEMATICAL BOLD ITALIC SMALL A (a, \ud835\udc82), все разные.
...
Составные символы Юникода отличаются от разложенных символов. Например, LATIN CAPITAL LETTER A ACUTE (Á, \u00c1) можно считать тем же самым, что и LATIN CAPITAL LETTER A (A, \u0041), за которым сразу следует NON-SPACING ACUTE (´, \u0301) при сортировке, но в идентификаторах они разные.
Это ни в коем случае не воображаемая проблема: α (U+03b1 GREEK SMALL LETTER ALPHA) и ⍺ (U+237a APL FUNCTIONAL SYMBOL ALPHA) - это разные символы!
Невозможно определить, какие символы являются допустимыми. Символы из вашего кода работают, но когда я использую ФУНКЦИОНАЛЬНЫЙ СИМВОЛ АЛЬФА, мой компилятор Java жалуется на "недопустимый символ: \9082". Даже если функциональный символ был бы более уместен в этом коде. Похоже, нет твердого правила о том, какие символы допустимы, кроме запроса
Character.isJavaIdentifierPart().Даже если вы можете добиться компиляции, сомнительно, что все реализации виртуальной машины Java были тщательно протестированы с идентификаторами Unicode. Если эти символы используются только для переменных в области видимости метода, они должны быть откомпилированы, но если это члены класса, они окажутся в файле
.class, что может привести к поломке вашей программы на ошибочных реализациях JVM.
В идеальном мире это был бы рекомендуемый способ.
К сожалению, вы сталкиваетесь с кодировками символов при выходе за пределы простых 7-битных символов ASCII (UTF-8 отличается от ISO-Latin-1, отличается от UTF-16 и т. Д.), Что означает, что в конечном итоге вы столкнетесь с проблемами. Это случилось со мной при переходе с Windows на Linux. Наши национальные скандинавские символы сломались в процессе, но, к счастью, только на ниточках. Затем мы использовали для всех них кодировку \ u.
Если вы можете быть абсолютно уверены, что никогда, никогда не столкнетесь с такой вещью - например, если ваши файлы содержат правильную спецификацию, - тогда во что бы то ни стало, сделайте это. Это сделает ваш код более читабельным. Если есть хоть малейшее сомнение, не надо.
(Обратите внимание, что «использовать неанглийские языки» - другое дело. Я просто думаю об использовании символов вместо букв).
Этот код хорош для чтения, но ужасен в обслуживании - я предлагаю использовать простые английские идентификаторы, такие как так:
double deltaTime = lastPollTime - pollTime;
double alpha = 1 - Math.exp(-delta....
выглядит хорошо, поскольку в нем используются правильные символы, но сколько в вашей команде будут знать нажатия клавиш для этих символов?
Я бы использовал английское представление, чтобы упростить ввод. А у других может не быть набора символов, поддерживающего эти символы, установленного на их компьютере.
Это совершенно приемлемо, если это приемлемо в вашей рабочей группе. Многие ответы здесь основаны на высокомерном предположении, что все программируют на английском языке. Программисты, не владеющие английским языком, в наши дни отнюдь не редкость, и они становятся все реже и все быстрее. Зачем им ограничиваться английскими версиями, если в их распоряжении совершенно хороший язык?
Помимо англоязычного высокомерия, есть и другие законные причины для использования неанглийских идентификаторов. Например, если вы пишете пакеты по математике, использовать греческий язык можно, если ваша цель - коллеги-математики. Зачем людям вводить «дельту» в вашей рабочей группе, если все могут понять «Δ» и, вероятно, набрать ее быстрее? Практически в любой проблемной области будет свой жаргон, и иногда этот жаргон выражается не латинским алфавитом. С какой стати вам захочется втиснуть все в ASCII?
Это отличная идея. Честный. Это просто нелегко осуществимо в то время. Давайте сохраним ссылку на него на будущее. Я бы любил видеть треугольники, круги, квадраты и т. Д. как часть программного кода. Но пока, пожалуйста, попробуйте переписать его, как предлагает Крозин.
Почему бы и нет? Если люди, работающие над этим кодом, могут легко набрать их, это приемлемо.
Но бог в помощь тем, кто не может отобразить юникод или не может его набрать.