Знаете эти госучреждения? У них столько специфических терминов, реквизитов, которые никак не переводятся. А еще есть длинные значения для учета, например ВыделенныеСредстваНаКапитальныйРемонтСистемыОтопления.
Если переводить это все промтом на английский, то такую программу для поддержки врагу не пожелаешь: AllocatedFundsForOverhaulOfTheHeatingSystem. Если сокращать, теряя смысл, то будет еще хуже.
Можно ли всю внутрянку в C# держать на русском языке, как в 1с, или это совсем не комильфо? Тогда как поступать?

Вообще, НЯЗ в шарпе можно переменные называть по-русски. Но "такую программу для поддержки врагу не пожелаешь"

VydelennyeSredstvaNaKapitalnyjRemontSistemyOtopleniya :)

Обычно переводят. Для примера можно взять тот же ВетИС и его названия классов.
Чтобы переводить "не промтом" и строить более короткие фразы, нужно немного знать язык, кроме того, в ряде случаев дополнительные слова, вроде "выделенные" в указанном примере, могут быть просто не нужны - если их убрать, то смысл фразы не поменяется.

(3) Спасибо, буду так делать.

На шарпе вполне ок и на русском

(0) HeatingSystemOverhaulFunds

(5) За такое руки отрывать надо

За перевод терминов на инглиш никто не заплатит. Ибо никто этого перевода не увидит

(8) Станет невозможно нанять индуса или румына в команду.

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

(10) А как в этих правилах принято переводить аббревиатуры? Например ОКЭД - основной классификатор экономической деятельности? OKED или MCEA (main classifier of economic activity)?

(11) Подозреваю, что MCEA, но в отдельной сноске создать таблицу аббревиатур с расшифровкой на английском и переводом на русский (для себя)

(11) если у вас есть команда (несколько разрабов), то вы можете собраться и обсудить этот вопрос. По итогам написать док, где это будет описано. А если вы один, то можете сами принять для себя волевое решение. Именем, так сказать, революции :)

делают и транслитерацию аббревиатур, и перевод. Оба подхода имеют право на существование.

Тут предлагают сокращать и давать комментарий. "Вменяемая ИДЕ при наведении покажет".

http://rsdn.org/forum/flame.comp/8073293?tree=tree

(0) врагу не пожелаешь код с короткими невнятными именами (Сум, Кол, Док). С длинными именами живется нормальнр

(8) наймут индуса, и будет он глазами кровоточить, смотря на этот код

(0) Когда я говнокодил на Java и C# то не парясь классы, переменные и методы по русски обзывал

(17) потом выследит тебя и убьёт )

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

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

(21) Читал, что научная литература 60х годов из СССР там очень ценится, как единственный внедренный источник знаний.

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

(0) Сокращай, не жмись, Порой KFC тоже сладок :)

(23) Казахский язык программирования еще не изобрели :)

(25) Там можно на русском писать.

(0)
_Obj1272
_Prop2181

я в питоне по русски все именую в своих скриптах

(28) Гореть теб

(20) ну так это крайность, крнст НамСовсемНиКЧемуИБоригГеоргиевичЗаЭтоНеПогладитПоГоловке

(29) чё это?

(31) Заслужил.

(22) топовые спецы черпают знания из первоисточников на инглише, потому что они только на нем и есть
в том числе не айтишники

(0) "Как в программах не 1С именовать классы, их поля, таблицы, если дословный перевод невозможен"
Этим вопросом в 1991году задались БГ и СГ, и решили именовать по русски

(7) (29) канибализм как он есть
а в других холиварных не 1с ветках миллион аргументов, почему руссяз это более чем норм)

крайне нежелательно именовать переменные и ф-ции по русски в языках которые изначально это не продрузумевали, в том числе и в (28) питоне

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

например в фронтэнде, я видел штуки которые динамически называют поля по названиям обхектов приходящих с бека, типа TextField_CustomerNameField - где CustomerNameField - это параметр в json пришедший с бека
А если оттуда придет ФИОПользователя..то в браузере, особенно пользователя из забугорья, да еще если админы криво настроили вебсервер (а всем всегда плевать на кодировки) то половина кода отвалится из-за кракозябров в исходниках, я такое частенько видел живьем

(36) типа TextField_;%:№;%%;?:? - unknown object

тоже самое и с путями к файловой системе в стиле c:\пользователи\юрий Львович!\Мои Ценные документики\файлик ворда.docx ...надо в какоенить лотус домино загрузить? велкам в c:\temp и файл переимновать без пробелов и по английски

(36) это у кого там ума хватает по русски именовать?

На самом деле,если название сложное и не очень понятное,то для денежного значения пишем Sum23,а уже в сноске и комментариях определяем,что это такое.
Потому как,в результате перевода может оказаться,что два разных показателя пришли в одну переменную,и потм сам черт не разберет,что там запрограммировано.
Опять же,можно еще указывать номе блока,чтобы номера были не очень большими - тогда путаницы меньше.
JsOn поддерживает unicode из коробки,но для всех символов,кроме первой полустраницы (ascii),будет отображаться через префикс \u и четыре шестнадцатиричных цифры,а из такой строки имя переменной построить сложно.

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

(20) с камином не работал. Но "говорящие" имена это хорошо, пусть и многословные. Проблема в том, что выбрать короткое лаконичное имя очень сложно. Ну и смотри, что лучше?

1. Увидеть процедуру ЗаполнитьАтрибут(), занырнуть в неё, прочитать 200 строк кода и только потом понять, что эта процедура заполняет реквизит НадежныйКонтрагент для тех покупателей, которые напокупали на миллион и не задержали ни одного платежа

2. Увидеть процедуру УстановитьПризнакНадежныйКонтрагентДляПокупателейСОборотомБолееМиллионаИБезПросрочекПлатежей()

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

(41) угумс. если она у тебя одна такая в когде.
а когда у тебя весь код такой вплоть до счетчиков циклов?
это что вместо головы должно на плечах быть.

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

(43) В нормальных иде скроллить не надо. Мышу наводишь - она тебе подсказку выдаст. Которую ты заранее написал.

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

(45) Так это твои проблемы, ты же создал так переменную

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

(46) что значит мои проблемы? Я как раз за самодокументирующийся код. И против экономии на длине имен

(0)Давай переменным короткие названия. А отдельно где-то держи нотацию, где можешь значение каждой переменной хоть на полстраницы расписать

(36) а как же сообщения на русском языке?

(41) а вот кстати в этом примере, УстановитьПризнакНадежныйКонтрагентДляПокупателейСОборотомБолееМиллионаИБезПросрочекПлатежей() --- это вышестоящая процедура которая должна внутри себя вызывать ЗаполнитьАтрибут()

поскольку ЗаполнитьАтрибут - должна быть универсальная ф-ция, а там где 'признакнадёжный' - уже бизнесовая

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

(51) блин да что вы гадаете, на ИТС уже все расписано, как называть процедуры и переменные и т.д.
https://its.1c.ru/db/v8std/content/647/hdoc

(52) "Как в программах *не* 1С"

(53) а почему нельзя эту практику перенести на другие языки? Или там так не принято?

(54) Речь идет не о названии ИменаРолейСПравомДобавления vs ПолучитьМассивРолейСПравомДобавления
А о названии ImenaRoleySPravomPolucheniya vs RoleNamesAllowedToRecieve vs roleNames // имена ролей с правом получения.

(55) мой же комментарий относился к (41) (51) а именно к именам функции из примера "УстановитьПризнакНадежныйКонтрагентДляПокупателейСОборотомБолееМиллионаИБезПросрочекПлатежей".
А если по теме ТС, то я бы использовал английские слова вместо транслита. Если есть хоть какая то доля вероятности, что этот код будет на аутсорсе у иностранцев, то тем более.

(51) код должен быть самодокументирующимся. Почти как в той поговорке: "На заборе слово из трёх букв, а за забором... действительно из трёх букв". Имя хорошего метода (конечного, а не на вершине стека) должно рассказывать, что же этот метод делает. Тогда отпадает необходимость заныривать внутрь метода и перечитывать его весь. В этом и смысл - делать код понятным, чтобы читающий его сразу же понимал и быстро по коду перемещался, а не штудировал часами портянки из кода

(57) вообще слово миллион там скорре всего не должно быть
его или в параметр или куда то в начало функции константой

(58) может и в параметр, а может и в имя функции. В бизнес-логике часто встречаются константы

(59) такое название функции выглядит как плохой код как по мне
я бы на ревью такое не пропустил

(60) ну классно, чё. Имя метода ЗаполнитьАтрибут() может выглядит красивее, только не говорит ни о чём, и порождает массу вопросов. Для тебя что проще, прочитать 10 слов [названия метожа] или прочитать 500 слов [содержимого метода]?

(61) я то про другое

(61) в ИТС же есть примеры, зачем вы неправильны приводите?
Пример с ИТС:
Неправильно:
Функция ПолучитьМассивыРеквизитов(ХозяйственнаяОперация, МассивВсехРеквизитов, МассивРеквизитовОперации)
Правильно:
Функция ЗаполнитьИменаРеквизитовПоХозяйственнойОперации(ХозяйственнаяОперация, ИменаВсеРеквизиты, ИменаРеквизитыОперации)

(63) *неправильный

(62) а про что?
Допустим, сделаю имя метода "красивым"

Процедура УстановитьПризнакНадежныйКонтрагенту()

а дальше, чтобы выяснить обрубленное ДляПокупателейСОборотомБолееМиллионаИБезПросрочекПлатежей, читающему всё равно придётся занырнуть в метод и прочитать его, чтобы получить тот самый обрубок

(63) что неправильно? ЗаполнитьАтрибут() я как раз привожу как плохое имя метода

(65) я про слово миллион
см (58)

(66) ну так ваш вариант не лучше

(65) а теперь представьте, что вам надо по десятку сегментов пройти (от 1-2лямов от 2-5 и тд.) вы будете на каждую сумму свою функцию лепить и код ее копипастом, только наименование подправить и число в запросе?)

(67) чем тебе слово миллион не угодило?

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

(70) тем что сегодня миллион, а завтра полтора

(71) как показывает практика, так не бывает)

(72) когда станет полтора, тогда и переименуешь

(73) сплошь и рядом. Вспомни хотя бы ставку НДС "0%"

(74) а у тебя эта функция к примеру экспортная и куча обработок внешних к ней долбится, вот прикольно будет)

(65) "читающему всё равно придётся занырнуть в метод" ему достаточно глянуть какая сумма в параметре передается.

(65) "БезПросрочекПлатежей" это так же в параметрах можно увидеть.

Если функция сложная, то есть возможность оставить комментарий к ней и к ее параметрам.

(76) вот зачем ты придумываешь нелепые примеры? В коде очень и очень много константных значений. Лучше раз в 10 лет переименовать метод, чем сотня человек тысячу раз заглянет в один и тот же метод и увидит: "а, тут всё тот же миллион"

коллеги, ответьте на мой вопрос (50)
если есть риск, что скрипт с русскими буквами на питоне не будет работать в каких то ситуациях, то как быть с русскими сообщениями типа print('привет') ?

И создавать функции в виде портянки на 200+ строк это тоже полохой код

(82) *плохой

(78) ты уже наговорил на метод с кучек побочных эффектов. Это тоже плохо. В такой метод будут заглядывать ещё чаще

если не знать предметки на английском лучше и не пытаться переводить, словите лулзов и русскоговорящим и get a fine от англоговорящих

(80) это не нелепые примеры, это лишь рекомендации к написанию кода. Я не видел ни одной функции, где константами бы прибивали параметры к имени функции. Это звучит так же нелепо как:
Процедура ЗаполнитьКонтактныеДанныеДляКонтрагентаВаси(Адрес,Телефон,КонтактноеЛицо и т.д...)
Я же вам предлагаю ЗаполнитьКонтактныеДанныеКонтрагента(Контрагент,СтруктураЗаполнения);

(84) "побочных эффектов" вы серьезно? Для вас Параметры функции это что то негативное?

(86) а это один из пиздецов программинга в 1с. Мы заведём отдельный регистр, напишем под него пять методов, заюзаем соединение с регистром в сотне запросов... И всё ради того чтобы катать какую-то константу, которая меняется раз в 10 лет

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

(88) вы опять куда то не туда, вас никто не призывает обезличивать функции и спецом усложнять, а наоборот писать самодокументирующие себя имена. Но тут тоже меру надо знать и не закладывать все подряд в имя функции, чтобы потом по каждому чиху отдела продаж не переименовать эти функции. В общем есть стандарты, надо придерживаться их, это мое мнение.

(89) не всё подряд, а что _конкретно_ делает этот метод. Если ты не прочитаешь "миллион" в названии метода, то всё равно прочитаешь его в коде метода

(90) давайте все же расмотрим частный случай, а именно ваш пример "УстановитьПризнакНадежныйКонтрагентДляПокупателейСОборотомБолееМиллионаИБезПросрочекПлатежей()"
Читая эту функцию, мы понимаем, что программист не заложил возможность пользователю менять сумму для установки признака контрагенту. Далее понимаем, что при изменении суммы, придется и переименовать саму функцию и исправлять все обращения к ней.
А можно же было тупо в запросе проверить подходит ли контрагент под надежного, а сам признак надежного дать в пользовательском режиме указать соответствующим юзверам. А для кодера достаточно будет глянуть параметры функции, чтобы понять какие соответствия нужны для этого признака.
Пример вашей процедуры всего лишь создает дополнительную работу программистам для изменении данного признака. А уж условия надежности клиента реально могут меняться хоть каждый год.
В общем убеждать вас у меня цели нет, свою мысль я надеюсь донес.

(91) в программировании зло:
- преждевременная оптимизация, когда она не требовалась (убили читабельность кода ради выигрыша времени размером в наносекунды)
- преждевременная универсальность, когда она не требовалась (добавили отдельные таблицы БД, написали универсальный код, нарисовали интерфейс, и всё во имя единственной константы, которая меняется раз в пять лет)

Мартин Фаулер в свой книге "Рефакторинг" описал правило трёх ударов:
1 удар. Делая что-то в первый раз, Вы просто это делаете.
2 удар. Делая что-то аналогичное во второй раз, Вы морщитесь от необходимости повторения, но все-таки повторяете тоже самое.
3 удар. Делая что-то похожее в третий раз, вы начинаете рефакторинг.

вот если _действительно_ возникнет потребность часто менять значение, тогда и заведешь константу, регистр, переименуешь метод и так далее. А заранее додумывая, и закладывая в код функциональность "про запас", ты выстреливаешь в ногу себе и другим программистам

(92) каждому свое, когда ты изначально планируешь архитектуру конфы, ты же не просто лепишь, что в голову пришло, а все таки прикидываешь, как будут данные хранится, как использоваться. Это как строить дом, можно составить проект изучить почву и начать строить по проекту, а можно тупо начать стоить, а если начинает обваливаться, или трескаться тогда и задумываться о дополнительном армировании/утеплении.
Я бы, реализуя такую хотелку бизнеса, сразу бы задал вопрос про использование и предложил возможность гибкой настройки данного признака в пользовательском интерфейсе.
Но как показывает практика, частенько программеры не в зуб ногой, тупо лепят, что им скажут без задней мысли, а как то предупредить, или предложить оптимальное решение чет мало кто делает. По опыту это все выливается в перелапачивание кода, а для бизнеса - в переплату по доработке.

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

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

А через 10 лет выяснится, что за последние 10 лет эта "гибкость" ни разу не понадобилась. Ибо пользователю юзают всё то же значение 1.000.000, которое 10 лет назад завёл программист Вася

(94) зато клиент осознанно заплатил за эту хотелку, либо отказался от нее. В этом случае претензий к кодеру не будет.

(95) претензий к кодеру может и не будет, но клиент переплатил за несколько часов абсолютно бесполезной работы кодера

(96) ты пропустил такие важные слова как "задал вопрос" и "предложил возможность"

(92) воо, у меня был начальник который в абсолют такую точку зрения возвел
разработка выглядела так
1) пилим фичу из 3 ф-ций связанных друг с другом для одного контрагента, делаем по шагам
2) пилим 1 ф-цию, прибиваем всё гвоздями, потому что лишний оверхед не нужен, вдруг остальные 3 не понадобятся? (1 неделя)
3) пилим 2 ф-цию + рефакторим первую чтобы всё работало вместе (1 неделя на ф-цию, 3 дня на рефакторинг первой)
4) пилим 3 ф-циб + рефакторим 1-ю и 2-ю чтобы всё работало (1 неделя + 1 неделя на рефакторинг
== (прошел месяц)
впиливаем 4 ф-цию и нахрен переписываем все три первые потому что там всё прибито гвоздями к одному контрагенту буквально 'найти(имя='ооо рогаикопыта')' (ну там по коду конечно в оригинале, я упростил) потому что оказалось что у контрагента 4 юрлица, а бизнесу так понравилась ф-ция что они хотят на всех клиентов её распространить

в итоге мы полгода пилим ф-цию вместо 2х недель просто потому что 'нечего писать лишнее пока это не требуется'
блин я там два года прострадал в этом балагане

(0) Убей всех своим кодом - пиши траслитом.

(98) писать код тоже нужно уметь. В среде 1сников это умеют не многие. Даже писатели типовых те ещё писатели. Как яркий пример рукожопств из недавнего - ставки НДС. В 2019-м подкатила новая ставка НДС 20%. И тут "внезапно" выяснилось, что в запросах типовых конфигураци 100500 раз идёт вычисление размера ставки НДС. Аццкое такое дублирование. В итоге было переписано овердохрена запросов. Но пришли к другому уродству - начали хранить ставки НДС в регистрах сведений. Всё почему? Потому что писатели типовых не знают что такое инкапсуляция, не знают и не чтят принцип единственной ответственности. Иначе логика вычисления аккуратно была бы инкапсулирована в одну глобальную функцию. Эта функция вызывалась бы прямо в запросах СКД, и в коде при обходе результата запроса. Добавление новой ставки НДС заняло бы у разработчиков типовых 1 час (добавить значение перечисления и добавить пару строк в глобальную функцию). Но из-за рукозадых подходов к разработке потратили 10.000 часов (условно)

Так о чём это я? Если у вас замена константы в коде на табличное значение проходило через пот, боль и слёзы... ну значит вы делали что-то не так