Вы должны использовать международные идентификаторы в Java/C#?
C# и Java позволяют использовать практически любой символ в именах классов, именах методов, локальных переменных и т. Д. Является ли плохой практикой использование не-ASCII-символов, проверка границ плохих редакторов и инструментов анализа и затруднение чтения некоторыми людьми, или американское высокомерие - единственный аргумент против?
11 ответов
Я бы придерживался английского, просто потому, что вы обычно никогда не знаете, кто работает над этим кодом, и потому что некоторые сторонние инструменты, используемые в процессе сборки / тестирования / отслеживания ошибок, могут иметь проблемы. Ввод äöüß на не немецкой клавиатуре - это просто PITA, и я просто считаю, что все, кто занимается разработкой программного обеспечения, должны говорить по-английски, но, может быть, это всего лишь мое высокомерие как не говорящего по-английски.
То, что вы называете "американским высокомерием", это не то, использует ли ваша программа международные имена переменных, а когда ваша программа думает, что "Währung" и "Wahrung" - это одни и те же слова.
Я бы сказал, что это полностью зависит от того, кто работает над базой кода.
Если у вас есть небольшая группа разработчиков, которые все используют общий язык, и вы никогда не планируете нуждаться в ком-то, кто не говорит на этом языке, для работы над кодом, тогда продолжайте и используйте любые символы, которые вы хотите.
Если вам нужно, чтобы над кодом работали люди разных культур и языков, то, вероятно, лучше придерживаться английского языка, поскольку он является общим знаменателем практически для всех в мире.
Если ваш бизнес не владеет английским языком, и вы думаете, что в Domain Driven Design есть что-то, то есть еще один аспект: как мы, как разработчики, можем использовать тот же язык домена, что и наш бизнес, без дополнительных затрат на перевод?
Это означает не только переводы между языками, скажем, английским и норвежским, но и между разными словами. Мы должны использовать те же слова, что и наш бизнес, для наших классов и услуг.
Мне было легче просто сдаться и использовать свой родной язык. Теперь, когда в моем коде используются одни и те же слова, стало проще разговаривать с экспертами моего домена. И через некоторое время вы привыкаете к нему, так же, как вы привыкли к коду без венгерской нотации.
Раньше я работал в команде разработчиков, которая с радостью стерла свои задницы с любыми соглашениями об именах (и в этом отношении с любым другим кодированием). Хотите верьте, хотите нет, но мне пришлось уйти в отставку, когда мне пришлось справиться с "а" и "ё" в коде. Несмотря на то, что я финн, я предпочитаю писать код с настройками клавиатуры США, потому что писать на финской клавиатуре вьющиеся и квадратные скобки - боль (попробуйте использовать alt, а также 7 и 0 для фигурных скобок).
Поэтому я говорю придерживаться символов ASCII.
Вот пример, где я использовал не-ASCII идентификаторы, потому что я нашел его более читабельным, чем замена греческих букв их английскими именами. Даже если у меня нет θ или φ на моей клавиатуре (я использовал копирование и вставку).
Однако это все локальные переменные. Я бы держал не-ASCII идентификаторы вне общедоступных интерфейсов.
Это зависит:
- Соответствует ли ваша команда каким-либо существующим стандартам, требующим использования ASCII?
- Будет ли ваш код когда-либо повторно использован или прочитан кем-то, кто не говорит на вашем родном языке?
- Представляете ли вы сценарий, в котором вам нужно будет обратиться за помощью онлайн, и, следовательно, вы не сможете скопировать и вставить свой пример кода как есть?
- Вы уверены, что весь ваш набор инструментов поддерживает кодировку кода?
Если вы ответили "да" на любой из вышеперечисленных вопросов, оставайтесь только в ASCII. Если нет, идите вперед на свой страх и риск.
Если вы преодолеете другие предварительные условия, у вас появится еще один (ИМХО более важный) один - насколько сложно набрать символ.
На моей обычной клавиатуре en-us я знаю только один способ ввода буквы ç - удерживать клавишу alt и нажимать 0227 на цифровой клавиатуре или копировать и вставлять.
Это будет ОГРОМНОЕ большое препятствие на пути быстрого набора текста. Вы не хотите замедлять кодирование такими банальными вещами, как это, если вас не принуждают. Международные клавиатуры могут облегчить это, но что произойдет, если вам придется кодировать на своем ноутбуке, который не имеет международной клавиатуры, и т. Д.?
Частично проблема заключается в том, что язык Java/C# и его библиотеки основаны на таких английских словах, как if а также toString(), Я лично не хотел бы переключаться между неанглийским языком и английским во время чтения кода.
Однако, если ваша база данных, пользовательский интерфейс, бизнес-логика (включая метафоры) уже написаны не на английском языке, нет необходимости переводить имена и переменные каждого метода на английский.
Я бы придерживался символов ASCII, потому что, если кто-то в вашей команде разработчиков использует SDK, который поддерживает только ASCII, или вы хотите сделать свой код открытым исходным кодом, может возникнуть множество проблем. Лично я бы не стал этого делать, даже если вы не планируете привлекать к проекту кого-либо, кто не говорит на этом языке, потому что вы управляете бизнесом, и мне кажется, что тот, кто занимается бизнесом, хотел бы, чтобы его бизнес расширялся., что в наше время означает выход за пределы национальных границ. Мое мнение таково, что английский - это язык области, и даже если вы называете свои переменные на другом языке, нет смысла использовать какие-либо символы, не входящие в ASCII, в ваших программах. Оставьте язык, чтобы справиться с ним, если вы обрабатываете данные с UTF8: моя программа на iPhone (которая включает в себя тонны пользовательских данных, передаваемых между телефоном и сервером), имеет полную поддержку UTF8, но не имеет UTF8 в исходном коде, Просто кажется, что такая большая банка червей открыта практически без пользы.
Существует еще одна опасность использования не-ASCII символов, хотя это, вероятно, будет кусаться только в неясных случаях. Разрешенные символы определяются в терминах методов Character.isJavaIdentifierStart(int) и Character.isJavaIdentifierPart (int), которые определяются в терминах Unicode. Однако точная версия используемого Unicode зависит от версии платформы Java, как указано в документации для java.lang.Character.
Поскольку свойства символов немного меняются от одной версии Unicode к другой, возможно (но, вероятно, очень маловероятно), что у вас могут быть идентификаторы, которые действительны в одной версии Java, но не в следующей.
Как уже указывалось, если имена методов в основном не соответствуют языку, немного странно постоянно переключать языки во время чтения.
Для скандинавских языков и немецкого языка, на которых я могу говорить и, таким образом, говорю, я бы по крайней мере рекомендовал использовать стандартные замены, т.е.
ä / æ -> ae, ö / ø -> oe, å -> aa, ü -> ue
и т.д. на всякий случай, так как другим может быть сложно набирать оригинальные буквы без изменений клавиатуры / раскладки клавиатуры. Подумайте, вдруг вам пришлось работать с кодовой базой, в которой разработчики использовали третий язык (например, французский) и не делали этого... Переключение между более чем двумя раскладками клавиш для эффективного ввода было бы болезненным в моем опыте.