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

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

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

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

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

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

По-разному:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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