Вы должны использовать международные идентификаторы в Java / C #?

Question

C # и Java допускают использование практически любых символов в именах классов, именах методов, локальных переменных и т. Д. Является ли плохой практикой использование не-ASCII символов, тестирование границ плохих редакторов и инструментов анализа и усложнение для некоторых людей читать, или американское высокомерие - единственный аргумент против?

Answer 1

Я бы придерживался английского, просто потому, что вы обычно никогда не знаете, кто работает над этим кодом, и потому что некоторые сторонние инструменты, используемые в процессе сборки / тестирования / отслеживания ошибок, могут иметь проблемы. Ввод äöüß на не немецкой клавиатуре - это просто PITA, и я просто считаю, что все, кто занимается разработкой программного обеспечения, должны говорить по-английски, но, возможно, это всего лишь мое высокомерие как не говорящего на английском языке.

То, что вы называете «американским высокомерием», это не то, использует ли ваша программа международные имена переменных, а когда ваша программа думает, что «Währung» и «Wahrung» - это одно и то же.

Answer 2

Я бы сказал, что это полностью зависит от того, кто работает над базой кода.

Если у вас есть небольшая группа разработчиков, которые все используют общий язык, и вы никогда не планируете, что вам понадобится кто-то, кто не говорит на этом языке, для работы над кодом, тогда продолжайте и используйте любые символы, которые вы хотите.

Если вам нужно, чтобы над кодом работали люди разных культур и языков, то, вероятно, лучше придерживаться английского, поскольку он является общим знаменателем практически для всех в мире.

Answer 3

Если ваш бизнес не владеет английским языком, и вы думаете, что в Domain Driven Design есть что-то, то есть еще один аспект: как мы, как разработчики, можем использовать тот же язык домена, что и наш бизнес, без дополнительных затрат на перевод? 1001 *

Это означает не только переводы между языками, скажем, английским и норвежским, но также и между разными словами. Мы должны использовать те же слова, что и наш бизнес, для наших классов сущностей и услуг.

Мне было легче сдаться и использовать свой родной язык. Теперь, когда в моем коде используются одни и те же слова, стало проще общаться с экспертами по моим доменам. И через некоторое время вы привыкаете к нему, так же, как вы привыкли к коду без венгерской нотации.

Answer 4

Раньше я работал в команде разработчиков, которая с радостью стерла свои задницы с любыми соглашениями об именах (и в этом отношении с любым другим кодированием). Хотите верьте, хотите нет, но мне пришлось уйти в отставку, когда мне пришлось справляться с ä и ö в коде. Несмотря на то, что я финн, я предпочитаю писать код с настройками клавиатуры США, потому что писать на финской клавиатуре вьющиеся и квадратные скобки - боль (попробуйте использовать alt, а также 7 и 0 для фигурных скобок).

Итак, я говорю придерживаться символов ascii.

Answer 5

Вот пример , где я использовал не-ASCII идентификаторы, потому что я нашел его более читабельным, чем замена греческих букв их английскими именами. Даже если у меня нет θ или φ на моей клавиатуре (я полагался на копирование и вставку.)

Однако это все локальные переменные. Я бы держал не-ASCII-идентификаторы вне общедоступных интерфейсов.

Answer 6

Если вы пройдете другие предварительные условия тогда у вас есть еще одна (ИМХО более важная) одна - Насколько сложно набрать символ.

На моей обычной en-us клавиатуре я знаю только один способ ввода буквы ç - удерживать alt и нажимать 0227 на цифровой клавиатуре или копировать и вставлять.

Это будет ОГРОМНОЕ большое препятствие на пути быстрого набора текста. Вы не хотите замедлять кодирование такими банальными вещами, как это, если вас не принуждают. Международные клавиатуры могут облегчить это, но что произойдет, если вам придется кодировать на своем ноутбуке, который не имеет международной клавиатуры, и т. Д.?

Answer 7

Это зависит от:

• Соответствует ли ваша команда каким-либо существующим стандартам, требующим использования ASCII?
• Будет ли ваш код повторно использован или прочитан кем-то, кто не говорит на вашем родном языке?
• Представляете ли вы сценарий, в котором вам нужно будет обратиться за помощью в Интернете, и, следовательно, вы не сможете скопировать и вставить свой пример кода как есть?
• Вы уверены, что весь ваш набор инструментов поддерживает кодировку кода?

Если вы ответили «да» на любой из вышеперечисленных вопросов, оставайтесь только в ASCII. Если нет, то идите вперед на свой страх и риск.

Answer 8

Часть проблемы заключается в том, что язык Java / C # и его библиотеки основаны на английских словах, таких как if и toString(). Лично я не хотел бы переключаться между неанглийским языком и английским во время чтения кода.

Однако, если ваша база данных, пользовательский интерфейс, бизнес-логика (включая метафоры) уже написаны не на английском языке, нет необходимости переводить имена и переменные каждого метода на английский.

Answer 9

Как уже указывалось, если имена методов в основном не соответствуют языку, немного странно постоянно переключать языки во время чтения.

Для скандинавских языков и немецкого языка, на которых я могу говорить и, таким образом, говорю, я бы по крайней мере рекомендовал использовать стандартные замены, т.е.

ä / æ -> ae, ö / ø -> oe, å -> aa, ü -> ue

и т.д.. на всякий случай, так как другим может быть трудно набирать оригинальные буквы без изменений клавиатуры / раскладки клавиатуры. Подумайте, вдруг вам пришлось работать с кодовой базой, в которой разработчики использовали третий язык (например, французский) и не делали этого ... Переключение между более чем 2 клавишными наборами для эффективного ввода было бы болезненным в моем опыте. 1007 *

Answer 10

Существует еще одна опасность при использовании не-ASCII символов, хотя, вероятно, она будет кусаться только в неясных случаях. Допустимые символы определены в терминах методов Character.isJavaIdentifierStart (int) и Character.isJavaIdentifierPart (int) , которые определены в терминах Unicode. Однако точная версия используемого Unicode зависит от версии платформы Java, как указано в документации для java.lang.Character .

Поскольку свойства символов немного меняются от одной версии Unicode к другой, возможно (но, вероятно, очень маловероятно), что у вас могут быть идентификаторы, которые действительны в одной версии Java, но не в следующей.