Речь пойдет об использовании в программном коде названий (классов, переменных, методов) на родном языке (в моем случае — на русском).
Опыт показал, что русские идентификаторы идеально подходят для создания объектной модели и для обсуждения ее с Заказчиком (для отечественных проектов).
Одна из общих тенденций развития ИТ — это постепенное “очеловечивание” технологий. Каждая новая технология поначалу ориентирована на узкий круг конкретных специалистов, но постепенно адаптируется под всё более широкий круг пользователей, в том числе разных культур. Взять хотя бы введение кириллических доменов (*.рф) – пусть еще не все браузеры нормально поддерживают отображение кириллических адресов, но процесс идет!
Начав заниматься программированием в начале 90-х, я никогда не испытывал проблем из-за того что файлы нужно было называть только латинскими буквами и не длиннее 8 символов, но когда в очередной версии Windows я понял, что этих ограничений больше нет — подумал: это же удобно! Каждый раз, давая название новому файлу, я по привычке думал: а что если этот файл попытаются открыть в системе, не поддерживающей кириллицу? Но вероятность этого становилась всё меньше, и со временем привычка исчезла.
Года три назад я вдруг обнаружил, что в dotNET можно называть идентификаторы любыми символами — английскими или русскими, неважно. Это следовало из того что dotNET ориентирован на работу с юникодом. Первое что пришло в голову — какими проблемами чревато использование русских названий? Поэкспериментировав в “русифицированным” кодом на разных версиях Windows и dotNET Framework, я не выявил ни одной проблемы.
Таким образом, я пришел к выводу, что в dotNET нет технических проблем с использованием русских идентификаторов.
Конечно, бывают случаи, когда вопрос использования русских названий отпадает сам собой:
Понятно, что наличие возможности не означает необходимость ее использования.
Я начал использовать русские идентификаторы практически во всех своих проектах. И со временем сделал для себя такой вывод: русские идентификаторы идеально подходят для создания объектной модели, а в остальной части кода они ни к чему.
Теперь пример:
Допустим, заказчик — учебное заведение и хочет систему учета учеников, классов, предметов, оценок и т. д. В разговоре с заказчиком вы используете слова “ученик”, “предмет”, “успеваемость” — так зачем же их в коде переводить на английский? Создаем объектную модель:
В VisualStudio создаем диаграмму классов:
Такую диаграмму классов даже можно показывать заказчику и при этом разговаривать с ним буквально “на одном языке” — то есть, используя одинаковые термины. У заказчика даже может возникнуть ощущение, что он неплохо разбирается в вашем коде :)
При этом, конечно, не следует увлекаться и называть в коде по-русски изначально англоязычные технические термины типа “File”, “Stream”, “Collection”, “WebClient” и т. п.
Общаясь с коллегами на эту тему, я замечаю, что отношение к русским идентификаторам со временем постепенно меняется. От резко отрицательного — к умеренно-снисходительному. Вот мой список причин, по которым программисты хотят писать код исключительно по-английски:
Кстати, недавно узнал, что 1С-программисты пишут код буквально “по-русски” :)
В заключение выводы:
Update: Буржуи, инструментами которых мы пользуемся при разработке, видят код как-раз на своем родном языке…
Опыт показал, что русские идентификаторы идеально подходят для создания объектной модели и для обсуждения ее с Заказчиком (для отечественных проектов).
Одна из общих тенденций развития ИТ — это постепенное “очеловечивание” технологий. Каждая новая технология поначалу ориентирована на узкий круг конкретных специалистов, но постепенно адаптируется под всё более широкий круг пользователей, в том числе разных культур. Взять хотя бы введение кириллических доменов (*.рф) – пусть еще не все браузеры нормально поддерживают отображение кириллических адресов, но процесс идет!
Начав заниматься программированием в начале 90-х, я никогда не испытывал проблем из-за того что файлы нужно было называть только латинскими буквами и не длиннее 8 символов, но когда в очередной версии Windows я понял, что этих ограничений больше нет — подумал: это же удобно! Каждый раз, давая название новому файлу, я по привычке думал: а что если этот файл попытаются открыть в системе, не поддерживающей кириллицу? Но вероятность этого становилась всё меньше, и со временем привычка исчезла.
Года три назад я вдруг обнаружил, что в dotNET можно называть идентификаторы любыми символами — английскими или русскими, неважно. Это следовало из того что dotNET ориентирован на работу с юникодом. Первое что пришло в голову — какими проблемами чревато использование русских названий? Поэкспериментировав в “русифицированным” кодом на разных версиях Windows и dotNET Framework, я не выявил ни одной проблемы.
Таким образом, я пришел к выводу, что в dotNET нет технических проблем с использованием русских идентификаторов.
Конечно, бывают случаи, когда вопрос использования русских названий отпадает сам собой:
- если Заказчик продукта зачем-то требует — чтобы весь код был на английском;
- если есть подозрение, что проект будет выложен в OpenSource или передан зарубежным разработчикам;
- если в команде разработчиков не все владеют русским языком;
- если проект является зоопарком различных языков и технологий (в том числе времен MS-DOS);
- если русские идентификаторы внесут путаницу в унаследованный код.
Понятно, что наличие возможности не означает необходимость ее использования.
Я начал использовать русские идентификаторы практически во всех своих проектах. И со временем сделал для себя такой вывод: русские идентификаторы идеально подходят для создания объектной модели, а в остальной части кода они ни к чему.
Теперь пример:
Допустим, заказчик — учебное заведение и хочет систему учета учеников, классов, предметов, оценок и т. д. В разговоре с заказчиком вы используете слова “ученик”, “предмет”, “успеваемость” — так зачем же их в коде переводить на английский? Создаем объектную модель:
В VisualStudio создаем диаграмму классов:
Такую диаграмму классов даже можно показывать заказчику и при этом разговаривать с ним буквально “на одном языке” — то есть, используя одинаковые термины. У заказчика даже может возникнуть ощущение, что он неплохо разбирается в вашем коде :)
При этом, конечно, не следует увлекаться и называть в коде по-русски изначально англоязычные технические термины типа “File”, “Stream”, “Collection”, “WebClient” и т. п.
Общаясь с коллегами на эту тему, я замечаю, что отношение к русским идентификаторам со временем постепенно меняется. От резко отрицательного — к умеренно-снисходительному. Вот мой список причин, по которым программисты хотят писать код исключительно по-английски:
- Лень часто переключать раскладку. Это странная проблема — типа частое переключение раскладки снижает производительность. Разве работа разработчика заключается в скоростном десятипальцевом набивании кода? По-моему, удобочитаемость кода важнее нескольких секунд (или даже минут) в день, потраченных на переключение раскладки. Почему же тогда программисты не жалуются когда пишут код вида Console.Write(«Привет, Мир!»); — ведь тут тоже нужно переключаться. Кроме того, эти же разработчики называют личные файлы на диске по-русски. Так что эта проблема “высосана из пальца” и означает что реальных проблем не нашлось.
UPD: Переключение раскладки при редактировании кода — это исключительно вопрос привычки. Мозг приспособится к этой задаче за два-три дня и это перестанет напрягать — проверено на опыте. - Чтобы код выглядел для непосвященных максимально сложным. Если код будет понятен заказчику, другим программистам, начальнику — то ведь у них может возникнуть мнение, что программирование — это не так уж сложно, что приведет к некоторому потускнению образа программиста, который как волшебник пишет какие-то никому непонятные символы… Другими словами, так проявляется желание выглядеть очень умным и незаменимым.
- Боязнь глюков Чтобы утверждать что из-за русских названий могут возникнуть труднообъяснимые проблемы — нужно хотя бы попробовать их использовать. А голословные утверждения, не подкрепленные практикой — это лишь прикрытие инертности мышления. В моей личное практике был один такой небольшой глюк (в Silverlight-проекте), но на фоне десятков других глюков он несущественен. Эта боязнь почему-то не мешает программистам работать на 64-битных русифицированных Windows и использовать локализованный Google J
- А вдруг код купят иностранцы? Если код пишется изначально с целью передачи иностранным заказчикам — тогда вопросов нет. В остальных случаях вероятность того что ваш код перейдет к буржуям или индусам — крайне мала. Если так – тогда и пользовательский интерфейс нужно делать исключительно по-английски, даже если конечный пользователь – бухгалтер в соседнем кабинете
- Объектная модель повторяет структуру БД. Часто объектной моделью приложения считаются таблицы в БД и связи между ними. В этом случае удобно называть классы и свойства так же как называются таблицы и поля в БД. Идеологически такой подход давно устарел – сейчас рулит Domain-driven design (DDD), при котором за основу берется предметная область заказчика.
Кстати, недавно узнал, что 1С-программисты пишут код буквально “по-русски” :)
В заключение выводы:
- Русские идентификаторы отлично подходят для описания объектной модели отечественных проектов
- Думаю — со временем разработчики перестанут бояться использовать русские идентификаторы
- Не нужно крайностей: писать по-русски весь код — абсурд.
Update: Буржуи, инструментами которых мы пользуемся при разработке, видят код как-раз на своем родном языке…
