Добрый день, форумчане.

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

Суть проекта - некая распределённая система обработки данных, где базы данных будут пополняться разными участниками проекта. В базах будут храниться различные формулы и ссылки на динамические данные и объекты. Так же будут использоваться методы и функции предопределённых объектов.

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

Мы попробовали сделать тестовый проектик с кириллицей, всё работает нормально. Проект базируется на Linux-системах с python 3.

Нужно ваше мнение - быть проекту с русскими названиями или всё-таки реализовывать на английском языке, согласно всем канонам доюникодовых инструментов и языков?

e_vladimir
некая распределённая система обработки данных

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

e_vladimir
В-общем, все в выигрыше и всем хорошо.

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

Стороннего ПО в проекте не будет. Вся аналитика будет строго внутренняя. Для экспорта/импорта данных есть строго документированные API и стандарты обмена данными. В этом и заключается одна из концепций данного проекта. Система строго автономна.

Все данные представляются в виде полноценного объекта, с возможностью обращения как к системным функциям и процедурам Python, так и вложенным. Типов объектов будет очень много, каждый тип объекта характеризуется своими параметрами и свойствами. Многие эксперты, которые будут работать с данной системой не знают английского языка (смежные языки для них - немецкий, французский, испанский и т.д.). Русский язык знают все, кто участвует в проекте.

В названиях папок и файлов - согласен, поддерживаю требования к названиям на англицком языке.

doza_and, насколько, с вашей точки зрения, будет оправдано применения промежуточного транслятора с русских названий в системные? Или может есть какие-то иные методы обращения к такому разношерстью данных? Просто у нас есть рабочий транслятор от прошлого проекта, который может преобразовывать данные “Объект.вложенный_объект.параметр” в sql-запросы к БД, которая нормализована до третьей степени.

Предполагается, что поток данных от экспертов и обычных пользователей будет достаточно большим. И не сколько большим, сколько разнородным. Весить данный объём на инженеров ПО - просто нерационально, тогда развитие проекта практически остановится. Плюс инженерам надо будет получать квалификацию по каждому разделу наук, в которой они будут обрабатывать данные, что бы понять что и как записать. Работа ведётся исключительно с данными, посредством инкапсуляции.

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

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

e_vladimir
Стороннего ПО в проекте не будет.

Так все говорят.

e_vladimir
Вся аналитика будет строго внутренняя.

Так все говорят.

Потом в один прекрасный день что-то меняется и из ниоткуда появляются новые и неожиданные требования. И от того, насколько твоя программа открыта к новому, зависит то, сможешь ли ты её встроить в абсолютно неожиданные условия.

wiki. философия UNIX

e_vladimir
Многие эксперты, которые будут работать с данной системой не знают английского языка

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

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

Например у нас часто приходится иметь данные с идентификаторами проекта некоторого предприятия Они могут содержать русские буквы, начинаться с цифры содержать амперсанды и другие спецсимволы. названия 1МЦ28Р#XQ12R и 1MC28R#XQ12R считаются одинаковыми. Некоторые проекты были реализованы с работающей системой нормализации идентификаторов. Это закончилось созданием сложной интеллектуальной системой проверки похожести идентификаторов по “созвучию”. Это не панацея. Такие идентификаторы все равно не могут использоваться как обычные идентификаторы в питоне несмотря на упомянутый utf-8. Пользователи лепят что в голову прийдет, интеллектуальная система не справляется. Системы в которых изначально не допускалось вольностей обозначений теперь работают намного стабильнее и у пользователей с ними меньше проблем.

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

Доводы резонные, спасибо doza_and, py.user.next.
Будем ваять по международным стандартам.