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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Итак, я говорю палку с символами ascii.

Ответ 5

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

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

Ответ 6

Это зависит:

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

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

Ответ 7

Если вы пройдете мимо других предварительных условий, у вас будет один дополнительный (более важный): насколько сложно напечатать символ.

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

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

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