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

Question

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Поэтому я предлагаю придерживаться символов ascii.

Answer 5

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

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

Answer 6

Это зависит:

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

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

Answer 7

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

На моей обычной клавиатуре в США единственный известный мне способ ввести букву ç - это удерживать alt и нажать 0227 на цифровой клавиатуре или скопировать и вставить.

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

Answer 8

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

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

Answer 9

Я бы придерживался символов ASCII, потому что, если кто-либо из вашей команды разработчиков использует SDK, который поддерживает только ASCII, или вы хотите сделать свой код с открытым исходным кодом, может возникнуть много проблем.Лично я бы не стал этого делать, даже если вы не планируете привлекать к проекту кого-либо, кто не говорит на этом языке, потому что вы управляете бизнесом, и мне кажется, что тот, кто управляет бизнесом, хотел бы, чтобы его бизнес расширялся, что в наши дни означает преодоление национальных границ.Мое мнение таково, что английский - это язык области, и даже если вы называете свои переменные на другом языке, практически нет смысла использовать какие-либо символы, отличные от ASCII, в вашем программировании.Оставьте это на усмотрение языка, чтобы справиться с этим, если вы обрабатываете данные в формате UTF8:моя программа для iPhone (которая включает в себя тонны пользовательских данных, передаваемых между телефоном и сервером) имеет полную поддержку UTF8, но не имеет UTF8 в исходном коде.Просто кажется, что открывать такую большую банку с червями практически бесполезно.

Answer 10

Существует еще одна проблема с использованием символов, отличных от ASCII, хотя она, вероятно, пригодится только в неясных случаях.Разрешенными символами являются определенный с точки зрения методов Символ.Является javaidentifierstart(int) и Символ.Является javaidentifierpart(int), которые определяются в терминах Unicode.Однако точная используемая версия Unicode зависит от версии платформы Java, как указано в документации для java.lang.Символ.

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

Answer 11

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

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

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

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