Интернационализация кода

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

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

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

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

Хорошая ссылка на эту тему: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

(Если кому-то интересно, я из Южной Америки, и английский не мой основной язык)

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

Я думаю, что решение о том, что разрешать, зависит от конкретного проекта, но я обычно терплю и в некоторых случаях поощряю деловые термины (например, имена объектов) на местном языке, но не технические термины (т. е. не Largeur/Hauteur вместо Width/Height) .

Например, в финансовом мире во Франции все знают, что означают OPCVM и FCP — если вы попытаетесь перевести английский язык, вы можете столкнуться с большим количеством недоразумений, чем если бы разрешили смешанные языки.

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

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

Комментарии и документация по коду на английском языке.

При разработке программного обеспечения с нуля я бы попытался найти английские термины для всех имен методов и даже бизнес-терминов (если это разумно. Я с трудом могу придумать пример, где термин не может быть найден), чтобы сохранить его «переносимым».

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

К сожалению, это не относится к кодированию. Английский не является моим родным языком, но я смог прочитать ряд технических статей и участвовать в международных конференциях с людьми со всего мира. Это сотрудничество просто не сработало бы, если бы все публиковались на своих родных языках.

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

Как правило, код, относящийся к языковым концепциям, должен быть на том же родном языке, что и язык программирования (т. е. на английском, поскольку, а строка — это все английские слова).

Это нормально (но не здорово) иметь переменные и понятия предметной области на местном языке, но вы определенно не хотите переводить List, Object, Decimal и т. д. в термины, которые заставляют программистов больше работать над согласованием двух языков. Тем не менее, я бы решительно лоббировал ограничение очень распространенных понятий домена, таких как Коллекция, Членство, Лицо, Пользователь и, возможно, менее распространенных понятий домена, таких как Счет, Квитанция, английским языком, где это возможно.

Это все равно, что программировать половину ваших занятий на VB, а половину на C# — ваш мозг должен совершить когнитивный сдвиг. Хотя это хорошо для гибридных приложений (JavaScript в Интернете и C# в бэкенде), поскольку помогает поддерживать четкость выполняемых действий, это не очень хорошо для общего программирования.

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

Всегда есть исключения. Есть определенные случаи, когда вы все равно использовали бы родное слово, когда слово лучше всего описывает домен. Например, в нашей (английской) кодовой базе у нас были ссылки на мексиканские испанские термины для определенных понятий, которые имели отношение только к людям, использующим наше программное обеспечение в Мексике. Как правило, японские термины произносились фонетически/ромадзи, однако не-японцам было трудно произносить пиктограммы ;-).

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

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

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

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

Третья причина, которая пришла мне в голову, — поделиться своим кодом на сайте, таком как SO. Сегодня я открыл пост с куском кода, где классы имели испанские названия. Мне было трудно догадаться, для чего нужен этот класс (даже если иногда и не нужно, но хорошо, когда читаешь код и понимаешь все используемые слова:)).

Подводя итог, я думаю, что интернационализация кода — не очень хорошая идея. Вы можете себе представить, что ключевые слова в языках программирования (например, class, try, while) также могут быть локализованы, и, вероятно, вы также можете представить, насколько тяжелой может быть тогда жизнь...

Чтобы сохранить согласованность, я бы сделал код на том же (человеческом) языке, что и язык (программирования). То есть, если в языке программирования используются английские ключевые слова (например, for, switch, public и т. д.), остальную часть кода оставьте на английском языке. Если вы используете компилятор, который распознает (скажем) переводы ключевых слов на суахили, остальную часть кода оставьте на суахили.

Многие API имеют стандартизированные схемы именования, которым следуют независимо от (человеческого) языка, а сопровождающая документация переводится по мере необходимости (вместо исходного кода).

Независимо от того, какой (человеческий) язык вы выберете, выберите один и придерживайтесь его. Я бы скорее попытался просмотреть исходный код на немецком языке, чем код, представляющий собой смесь немецкого и английского языков.