Имена переменных и знание языка

Вот мировая проблема-то! Особенно если учесть, что в каждой стране свои правила документооборота

Я надеюсь, что ты не используешь глобальные переменные там, где не нужно

В данном контексте «переменная» — обобщённое название для {класс, тип, функция, переменная, ключ таблицы, имя файла}.

Как? Report1, Report2, Report100500 а в документации указать какой номер какому отчёту соответствует?

С фантазией и словарным запасом совсем туго, кроме неспецифичного report нет слов с более узким смыслом? Выбор ёмкого и просто (короткого) идентификатора для сущности должен быть рутинной деятельностью разработчика.

За бухгалтерию в отличие от всего остального платят сразу и всегда

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

acidity

Что-то везде переводится как кислота/кислотность...

Бухгалтерия это именно такое днище в котором никуда невозможно вырасти.

Почему никуда? На её базе конторы часто строят АСУП. Или автоматизированная система управления предприятием — тоже днище?

С фантазией и словарным запасом совсем туго, кроме неспецифичного report нет слов с более узким смыслом?

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

Особенно если учесть, что в каждой стране свои правила документооборота

Именно поэтому и вопрос. Типа «зачем иностранные наименования в русской программе».

Объясни какой смысл писать turnover balance, если без гугла никто не поймёт что это

Зачем мы пишем «брокер», а не посредник, «дорожная карта», а не план и ещё кучу заимствованных слов? Наверное, смысл в этом же.

Голосую за turnover

Тут и не нужно. А если такие требования, вставь от балды, близкое по смыслу

вставь от балды, близкое по смыслу

От балды мне проще написать «ОборотнаяВедомость» :-) По крайней мере сам найду когда искать буду.А если язык неуникодный, то «reportOV».

От балды мне проще написать «ОборотнаяВедомость»

Так и сделай. Серьёзно. Будет какой-нибудь афроамериканец читать твой код, ему придётся разбираться, что это. Разберётся - ничего не испортит.

А так ты криво переведёшь, он тебя криво поймёт. Глухой телефон.

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

tr_oborotnaja_vedomost

А так ты криво переведёшь, он тебя криво поймёт. Глухой телефон.

Вот! Резюмирую: если объект предметной области не имеет прямого перевода (полного аналога в англоязычном мире), то лучше использовать транслит.

Аналогично при переводе с английского: тред, стрим, компьютер лучше чем нить, поток, вычислитель.

Зачем мы пишем

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

Терминология в коде должна строго совпадать с терминологией предметной области. Если твой язык не позволяет называть сущности по-русски, то выкинь такой язык. А за транслит надо убивать.

Вот станет русский язык ведущим мировым языком

Так мы же пишем «брокер», а не «broker»; «дорожная карта», а не «roadmap»...

Это не иностранные термины. Это как раз тот самый транслит: samovar, turnover balance ...

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

А за транслит надо убивать

То есть, если я буду делать такой отчёт: http://honii.com/images/pa0611.png , то лучше писать

class 付款明细表 : public AccountReport {
...
}

class  fukuanmingxiReport : public AccountReport {
...
}

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

Комментарий-то будет. Вопрос про само имя. Фактически выбор между

а) отдалённо похожим объектом (нужен единорог, но такого слова не знаем, пусть будет носорог),

б) правильным названием транслитом,

в) правильным названием кириллицей.

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

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

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

В такой ситуации - только транслит, только хардкор. Это лучше, чем заведомо неправильный перевод. Причем такие ситуации бывают не только в России.

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

activity report

словарей хороших надо иметь

balance list например, но не красиво

вы еще в математику включите русские буквы

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

специалист должен источать профессионализм

vodka писать можно oborotka нельзя но можно если это раскрученный брэнд или на устах у всех как типа perestroika

activity report

Уверен?

http://www.businessdictionary.com/definition/activity-report.html

«It includes information such as (1) number of customer visits made, (2) demonstrations performed, and (3) new accounts opened »

Или дай подтверждающую ссылку.

с идиотского псевдоучетного законодальства ничего не отражающего в реальности

Ты его хоть знаешь?

создающее условия для процветания «черной экономики»

Но «Lehman Brothers», кредиты под залог гудвила и «доход» у организации, когда она уменьшает свой капитал (распродаёт свои основные средства) не у нас, а в США.

Всегда стараюсь выбирать правильные термины, если знаю о чём речь. А если я неправильно употреблю какой-нибудь БИК или ИНН или ОРГН (которые я понятия не имею ни как они будут использоваться, ни что это, ни зачем они нужны вообще), то тут пофиг, что переводить, что транслитом написать. Для меня это просто буковки и поля в БД.

Нашел (вроде такой) отчёт в Microsoft Dynamics. Называется (внезапно) «Summarized general ledger» 8-)

то тут пофиг, что переводить, что транслитом написать

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

Не обалдеешь раскладки всё время переключать (всякие for на английском, а строка_данных на русском) (если не 1С, конечно)? За такое по голове надо больно бить.

ТС, учи английский, вот и всё. Если осилить его не можешь, то уходи из программирования, не твоё это.

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

Пиши просто:

class  fReport : public AccountReport {
...
}

class  fukReport : public AccountReport {
...
}

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

На кой ляд английский в русской бухгалтерии?

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

Те статьи на российскую бухгалтерию очень плохо ложатся. У них единица учёта «раздел учёта (assets, liability, ...)», у нас — бухгалтерский счёт. Обороты у них только в cash flow, expenses, income. subledger — тоже не совсем «карточка счёта», ближе к нашему «налоговому регистру».

На кой ляд английский в русской бухгалтерии

Так язык программирования ведь в английских терминах. Или предлагаешь любую бухгалтерию писать как 1С: начинать с

#define для for
#define цел int
...

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

Не обалдеешь раскладки всё время переключать

Ставишь себе переключалку раскладок на Caps Lock и нажимаешь её мизинцем. Требуется, конечно, некторое мысленное усилие, чтобы переключиться с одной раскладки на другую, но в целом это не критично.

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

Остаётся только аргумент:

Имена переменных и знание языка (комментарий)

Хотя, если для каждой страны отчёты должны дорабатывать только те, кто нормально знают язык этой страны, то, действительно, лучше оборотная_ведомость и 付款明细表 (отсевает лишних).

Хотя, если для каждой страны отчёты должны дорабатывать только те, кто нормально знают язык этой страны

Я не понимаю, у тебя программа для одной страны или для разных?

Я не понимаю, у тебя программа для одной страны или для разных?

Сейчас для одной. Но глядя на претензии на http://habrahabr.ru/post/218073/ «Деодар» - новая рабочая среда для Linux хочу сделать потенциально интернационализируемой (алгоритмы-то те же). Вот и спрашиваю мнение сообщества, как лучше, чтобы не обзывали быдлокодом.

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

Вот и спрашиваю мнение сообщества, как лучше, чтобы не обзывали быдлокодом.

Всё равно обзовут, как бы ты ни сделал. Как в картинке про осла и общественное мнение.

Всё равно обзовут, как бы ты ни сделал.

К концу этого обсуждения я тоже к такому мнению склоняюсь. Я надеялся на большее единодушие в выборе перевод/транслит/кириллица. Тогда можно было бы хоть сослаться на это обсуждение в случае чего. :-)

Ладно, для себя я решение принял и хорошо.

хочу сделать потенциально интернационализируемой

Не надо

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

Транслит - зло, потому что зло.

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

Опиши обжикт типа коллекция с метаданными типа тайтл лэйбл локале нейм даже может обжикт с локальной инфо

Опиши обжикт типа коллекция с метаданными типа тайтл лэйбл локале нейм

А кто-то тут говорил, что «за транслит убивать надо» (с) :-)))))

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

Report

Plus method. findByLocaleTitle

Транслит крайняямера самопозор

findByLocaleTitle

А чем имя в кириллице/иероглифах хуже?

Если делать "... тайтл лэйбл локале нейм ...", то тайтл всё равно надо бы транслитом (или переводом где возможно). А если нет, то чем «тайтл» от «локале нейм» будет отличатся?

возьми аналог локализованные версии софта или javascript - там везде юникод и тем не менее управляющие сущности это стандартный набор символов.

код на международном языке остальное, что можно локализация.

Примерно так: locale/i18n()->title() это уже как там напишут, но еще никому в голову не приходило в качестве первичных идентификаторов объектов задействовать локальный алфавит, хотя допустимо использовать дополнительный ключ типа «ЁЫ123», но должен быть и ключ YOYU123.

Традиционно, в силу переносимости это таблица 256 символов и то это вариант расширенный, лучше 128. Остальное уже локальные наборы.

Вообще, проверка на «вшивость» классическая - тест поддержки локализации (русских букв)

Необходимость писать языковые методы объекта транслитом или в локальном варианте сигнализирует, что в архитектуре есть проблемы или что-то не так или что-то не доделано или схалявили... Отчет может быть описан одним идентификатором, но как правило у него есть свой набор атрибутов/реквизитов