Нелатинские буквы в исходном коде

Нелатинские буквы в исходном коде: идентификаторах, комментария и т.д.

Компиляторы C#, Си++, других языков, многие SQL серверы поддерживают Юникод не только в строковых литералах, но и на уровне лексического анализатора. Я всё чаще слышу утверждения, что этой функциональностью надо пользоваться. Хочу высказаться и привести свои аргументы, почему так поступать не следует.

• Не всё что поддерживается является полезным или приемлемым. Оператор goto поддерживается, но этот факт не является аргументом в пользу использования goto. Так же и идентификаторы содержащие национальные символы не следует использовать только лишь потому что так можно делать.


• Английский язык не ограничивает выразительные возможности. Терминология практически всегда однозначна и всегда общепринята.
  
  Более того, словообразование английского языка хорошо соответствует потребностям технических писателей. Например, существительные естественным образом выступают в роди прилагательных, а для любого действия можно задать активного и пассивного участника суффиксами er (or) и ee. Другие языки могут обладать менее обобщённой или менее однозначной системой словообразования.


• Подавляющее большинство языков программирования не поддерживают ключевых слов на языке отличном от английского. Использование нелатинских букв приведёт к постоянным переключениям раскладки. Не всем кто будет поддерживать код это может быть удобно.
  
  Существуют языки поддерживающие неанглийские ключевые слова, например, скрипт 1С. Однако, код с ключевыми словами на непривычном языке или, того хуже, разных языках, читается существенно медленнее. А код как известно читается гораздо чаще, чем пишется.


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


• Обмен кодом с окружающими становится труднее. Например, код нельзя скопировать на популярнейший форум stackoverflow.com, где большинство участников не понимает языка кроме английского. Попытки переделать код в форме редактирования сообщения приведут, скорее всего, к синтаксическим ошибкам и ложно правильным ответам.


• Зачастую, в неанглийском языке нет устоявшейся терминологии, либо она не имеет однозначного соответствия с английской. Например код

  Поток СоздатьПоток();

  может быть воспринят и как

  Thread CreateThread()

  и как

  Stream CreateStream();

  Кроме того, отдельную проблему создадут общепринятые сокращения. Как локализовать название ReadXml? ПрочитатьXml? А может ПрочитатьАЯР потому что eXtensible Markup Language это рАсширяемый Язык Разметки?
  


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

  foreach (object in collection)

  за исключением скобок читается как обычное предложение. А вот о

  длякаждого (объект в коллекция)

  такого сказать нельзя.



• Хотя конкретный компилятор может поддерживать нелатинские буквы и неанглийский язык, это не всегда можно сказать о среде разработки. Например, расширение Visual Studio GhostDoc автоматически генерирует документацию делая, вообще говоря вполне разумное, предположение, что имена методов это английский глагол за которым опционально следует английское существительное. Инструменты проверки качества, такие как FxCop и повышения производительности, такие как ReSharper и VisualAssist, содержат множество правил отвечающих за грамотность написания идентификаторов. Аналогичных инструментов для других языков может не быть.

Резюме: пальцы ломать за идентификаторы не на английском.