Давайте обсудим.
Потом прикручу пост и голосовалку.

Что с венгерской нотацией? Сразу в бан?
Что с длинными именами?

Должно ли быть слово Получить у функции?

ПолучитьНаименованиеНоменклатуры
сразу в топку, автора - на кол
НоменклатураНаименованиеПолучить
лампово, православно-кошерно

Я щетаю, что плохие имена переменных выдают плохое понимание предметной области и контекста. Кстати, это признак бота.

(2) Угу. Вся БСП - писана ботами

(0) >>?Что с венгерской нотацией? Сразу в бан?

Устарела, видел в основном в сторонних обработках(от "Контура", например) и отраслевках.

>>Должно ли быть слово Получить у функции?

1С не одобряет, но таких функций в типовых еще много.

(3) не исключено

(4) если у меня переменная типа СправочникОбъект, я обзываю её оКонтрагент
При этом переменная Контрагент является ссылкой

(0) А смысл? Через пару-тройку лет кто вообще будет код читать, кроме ботов?

ааа ... так вот кто аффтар имен переменных в клюшках о какого нить Папука: гллгбткуСчетчик = 0;

(1) >НоменклатураНаименованиеПолучить

Когда окромя Номенклатура еще много разных то примерно так и делаю
С именами переменных аналогично
Не "КодНоменклатуры" а "НоменклатураКод", "НоменклатураНаименование" и т.д.

(0) Слово "Получить" как и прочие типа "Найти", "Создать", или совмещенное "НайтиСоздать" могут присутствовать по необходимости
Для удобства и отличия процедур/функций, аля разных действия с одним видом объекта

Если просто сделать имя функции Номенклатура() - хрен поймешь что это и зачем
И как потом дописывать другие функции
Так что сразу НоменклатураПолучить() или ПолучитьНоменклатура()

(9)+ Кстати в последнее время иногда развлекаюсь через структуры
Вместо "НоменклатураКод", "НоменклатураНаименование" делаю структуру "Номенклатура" и у нее значения с ключами "Код" и "Наименование"
Для логичных обращений Номенклатура.Код и Номенклатура.Наименование
И внутри структуры могуть быть другие структуры или массивы а не только простые типы

Венгерская нотация удобна для чтения
Но неудобна для написания-разработки

Длинные имена это хорошо! Пока они на экран влезают ))

(0) И вы туда же... Роберт Мартин, Стив Макконнелл и Волшебник :).
А по сути:
1) Венгерская нотация - используется только если это описано во внутренних стандартах проекта. Многие топовые программисты с которыми я работал используют её, но есть общие правила - поэтому иногда приходилось просить переписывать.
2) Длинные имена - хороший стиль требует использование длинных имен, для однозначного определения значений переменных, сокращения допускаются в рамках общепринятых сокращений. Код должен быть понятным программисту, который будет работать после вас.
3) По поводу "Получить", "Установить" и т.д. - лучше не использовать, но иногда для повышения читабельности кода допустимо.

Тут ещё момент с реквизитами формы всплывает, поэтому иногда не зазорно в процедуре или функции "экранировать" потенциально опасные имена переменных.

Во-первых, мне не нравится стандарт 1С о наименовании переменных https://its.1c.ru/db/v8std/content/454/hdoc

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

Я имена локальных переменных метода начинаю с маленькой буквы. Тогда хоть как-то понятна область её действия.
Параметры методов я часто начинаю с "п", если имя параметра может конфликтовать, например, с именем свойства или реквизита.
Переменные модуля, коли таковые есть, я предпочитаю начинать с "м" по той же самой причине: показать область действия (и "червячок", что от них надо избавляться).
Имена локальных методов модуля я так же стараюсь начинать с маленькой буквы.
С "_" у меня начинаются имена общих модулей, которые реализуют "библиотечные" методы, не относящиеся к бизнес-логике и поведению метаданных и интерфейса, типа "синтаксического сахара".
Например, "_Массивы" - содержит общие методы для работы с массивами. У меня есть даже модуль "__", содержащий наиболее часто используемые "хелперы". Например, __.ЕслиНеопределено() или __.ЭтоСегодня() и т.д.

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

(14) А какой смысл использовать однобуквенные сокращения?
Да еще в нижнем регистре, который 1С не отличает?

Имхо сделать префикс и писать с ним
пИмяПараметр = ПараметрМетодаИмяПараметра
мИмяПеременной = ПеременнаяМодуляИмяПеременной
"_Массивы" - почему не обозвать нормально и вызывать ОбщегоНазначенияМассивы.ИмяМетода()

(15)+ Я к тому что букв мало, на все случаи коротких префиксов не хватит
А слов много - лучше писать словами понятно сразу без изучения специфической нотации
И не ограничиваться "п", "м" или "_" - разделять нормально! И будет сразу всем понятно!

(15) (16)+ А еще лучше использовать структуры
Зачем заводить кучу "п" или "м"
Когда можно создать одну структуру и внутри нее хранить
По имени структуры все понятно, внутри как хочется обзывать

Пишите-пишите, я конспектирую...

(7) вы считаете себя не ботом?

(15) где я написал про "однобуквенные сокращения"? такого я не писал

сравни:

Процедура КакойТоМедодОбработки(ПараметрНоменклатура, ПараметрКонтрагент, ПараметрОрганизация); 

   Номенклатура = ПараметрНоменклатура;
   Контрагент = ПараметрКонтрагент;
   Организация = ПараметрОрганизация;

КонецПроцедуры

или

Процедура какойТоМетодОбработки(пНоменклатура, пКонтрагент, пОрганизация);

   Номенклатура = пНоменклатура;
   Контрагент = пКонтрагент;
   Организация = пОрганизация;

КонецПроцедуры

или

МассивЧегоНибудь = ОбщегоНазначенияМассивы.НовыйМассив(ЧтоНибудь, ЕщеЧтоНибудь, ИЕщеЧтоНибудь);

массивЧегоНибудь = _Массивы.НовыйМассив(
  ЧтоНибудь,
  ЕщеЧтоНибудь,
  ИЕщеЧтоНибудь); 

Я не против длинных имен, я даже наоборот очень за.
Но я хочу, чтобы имена уменьшали когнитивную нагрузку, а не увеличивали её.
И чтобы было меньше "смыслового мусора".
"ПараметрМетода", "ОбщегоНазначения" - это смысловой мусор.
И 1Совские "КлиентСерверПовтИспПереопределяемый" - это тоже смысловой мусор, от бедности и безысходности

(20) Сравни

Процедура КакойТоМедодОбработки(ПараметрСтруктура); 

   Номенклатура = ПараметрСтруктура.Номенклатура;
   Контрагент = ПараметрСтруктура.Контрагент;
   Организация = ПараметрСтруктура.Организация;

КонецПроцедуры

(20) >"ПараметрМетода", "ОбщегоНазначения" - это смысловой мусор.

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

В типовых 100500 модулей начинается одинаково.
Поэтому, ctrl+пробел не спасает.
Проще поставить "_" и дойти до нужного, чем выбирать из дохера вариантов

(21) Теперь тебе еще надо как-то проверить, что в этой структуре именно те свойства, которых ты ожидаешь.
Без типов такой стиль очень небезопасен

(21)+ когда надо допиливать - не приходится изменять объявления методов
только внутрь составного параметра докинуть и все

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

(21) хуже всего, конечно,

Процедура КакойТоМедодОбработки(ПараметрСтруктура); 

   ЗаполнитьЗначенияСвойств(ЭтотОбъект, ПараметрСтруктура);

КонецПроцедуры

и такое в типовых встречается

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

(23) Используй Сервис - Шаблоны текста
Там есть замена

(24) Не надо
Точнее тогда надо и кучу параметров метода проверять ))

(25) когда в платформе будет нормальная проверка типов. а не вот это вот //@strict-types

(26) Это идеальный код!
Даже доработки не нужны когда новое внутри ЭтотОбъект и ПараметрСтруктура добавляется, причем имена совпадают
Вот если нужно иное перекрытие или не полное заполнение приходится с доп.параметрами ЗаполнитьЗначенияСвойств() возиться

(30) Это уже будет не 1С а нечто иное
Согласен что строгая типизация лучше
Но нетути

1С плодит программистов-уродов.
Это хреново, конечно

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

Называйте, как хотите. Но реализуйте всё функциями, возвращающими структуру с результатом

Функция ПолучитьКонтрольноеЧислоGS1(Знач ID) Экспорт
    СтруктураВозврата=Новый Структура;
    СтруктураВозврата.Вставить("Результат",Истина);
    СтруктураВозврата.Вставить("ОписаниеОшибки","");
    СтруктураВозврата.Вставить("КонтрольноеЧисло",Неопределено);
    
    Если АСФОбщегоНазначенияКлиентСервер.ЕстьНеЦифрыВСтроке(ID) Тогда
        СтруктураВозврата.ОписаниеОшибки="Переданный идентификатор семейства GS1 должен содержать только цифры.";
        СтруктураВозврата.Результат=Ложь;
        Возврат СтруктураВозврата;
    КонецЕсли;

(35) Тоже дошло что Процедуры не нужны?
Достаточно Функций

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

(34) Но когда рядом
НаименованиеНоменклатуры()
ЗаполнитьНаименованиеНоменклатуры()
СформироватьНаименованиеНоменклатуры()
то без префикса выглядит странно

(31) "Это идеальный код!" - у "нормального" программиста от такого вытекают глаза и волосы дыбом встают

(37) Если параметров >2 - стараюсь сразу делать структуру

(1) Тут борются два начала: рациональное и прекрасное
Рациональное говорит пиши все без падежов типа НоменклатураНаименованиеУстановить
Прекрасное требует УстановитьНаименованиеНоменклатуры
Я за прекрасное, потому что чаще всего функции и процедуры довольно уникальны, а не так, что сто функций с примерно одинаковой логикой
А если уж их сто, тогда вопрос с чего бы их сто, а не одна с параметром, который может принимать сто значений
А когда процедура или функция одна и называется НоменклатураНаименованиеУстановить, то хочется взять автора за шкирку и долго и внимательно выразительно смотреть ему в глаза

(39) А есть утвержденные тесты для проверки "нормальности" программиста?

(41) >с чего бы их сто, а не одна с параметром

И с кучей Если ИначеЕсли внутри?
И вызовом других?? А как насчет их имен?

(41) >хочется взять автора за шкирку и долго и внимательно выразительно смотреть ему в глаза
Иногда надо сразу думать на будущее
Так влом написать "лишние" буковки?
Зато потом картинка более стройная и понятная
И можно поиском по "Установить" найти/перебрать все нужные методы

НастоящиеПрограммистыПробеламиИСимволамиПодчеркиванияНеПользуются()

(45) "Настоящие программисты используют кавычки"."Для вызова методов"()
!

(35) у меня для такого "псевдомейби" есть

типа:

Если ошибка Тогда
  Возврат _Результат.ВернутьОшибку(текстОшибки);
Иначе
  Возврат _Результат.ВернутьДанные(данные);
КонецЕсли;

и используется:

ответ = ЧтоТоНадоСделать();
Если НЕ _Результат.ЭтоОшибка(ответ) Тогда
   данные = _Результат.ДанныеИз(ответ);
Иначе
   ВызватьИсключение _Результат.ОшибкаИз(ответ);
КонецЕсли;

(46)+ Это вы еще кода на китайском с именами (переменных, методов и т.д.) из иероглифов не видали...

(21) Нечитабельно и хрен проверишь ошибки в конфигураторе, на кол

(47) ПиПиПи...
Тех кто использует исключения для возврата результата метода - ждет отдельный котел

(49) В конфигураторе и так хрен что проверишь
Только в режиме предприятия при выполнении кода

(31) Говно это, а не идеал
Все копирования свойств должны быть явно указаны, а не по принципам:
— Если появился новый реквизит, то скорее всего его тоже нужно заполнять, давай заполним
— Если удалили или переименовали реквизит, то и ничего страшного, не будем ругаться, просто заполним остальные свойства, а на этот хрен забьем

(50) где ты там возврат увидел, болезный?

(43) Куча Если ИначеЕсли для установки наименования объекта?
А вы точно программист?

(53)

   данные = _Результат.ДанныеИз(ответ);
Иначе
   ВызватьИсключение _Результат.ОшибкаИз(ответ);

Логично предположить что это внутри функции и данные возвращаются?
Или не возвращаются ибо упс происходит исключение
Приходится заворачивать такое в Попытку

Если это не внутри функции и/или прерывание кода нормально то ок

(54) Нет для разной обработки одной сущности
В этом случае логично делать разные методы с понятными именами
А не портянку внутри одного метода

(44) Не надо при создании обработки заполнения реквизита в существующих контрагентах сразу строить ее на БСП и предусматривать, что она может начать использоваться в англоязычных странах
Будет необходимость — добавишь
Не будет — будет чище код, без всяких мутных вещей, добавленных на случай а вдруг

(45) А вот тут, кстати, да, я бы, если бы был начинающим одинесником и понял бы этот момент, пользовался бы подчеркиваниями, конечно

(56) Если разность в том, что нужно либо наименование присвоить либо на удаление пометить, то это как бы разные вещи и разные процедуры, конечно же
А если нужно присвоить либо наименование либо код либо автора, то и че и че, просто параметр

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

(41) примерно так:

Процедура УстановитьСтатус(Знач Документ, Знач Статус) Экспорт
   // логика стейт-машины
КонецПроцедуры

Процедура УстановитьСтатусОжидание(Знач Документ) Экспорт
   УстановитьСтатус(Документ, Перечисления.СтатусыОпераций.Ожидание);
КонецПроцедуры

Процедура УстановитьСтатусВыполняется(Знач Документ) Экспорт
   УстановитьСтатус(Документ, Перечисления.СтатусыОпераций.Выполняется);
КонецПроцедуры

Процедура УстановитьСтатусВыполнено(Знач Документ) Экспорт
   УстановитьСтатус(Документ, Перечисления.СтатусыОпераций.Выполнено);
КонецПроцедуры

конечно, если этих вариантов не более 5-6.

я все время страдаю
писать типа
Если а=1
или
Если А = 1

Если пишу сейчас полную ветку
Если КакаяТоХрень()=1 Тогда // типа ничего, норма
Иначе
   // всякая шняга пишу тут
КонецЕсли;

(61) Такая логика полезна когда код внутри чуть посложней
Не просто сразу УстановитьСтатус а по неким условиям

Но вот Знач совершенно лишнее ибо тип не простой

(64) откуда ты знаешь, что тип не простой? Или Ссылка для тебя сложный тип?

(1) А еще так учат отдавать приказы. Уж несколько тысяч лет как

(41) Полностью согласен.

(61) (64) а потом вздохи про глубокий стек вызова процедур в типовых... ;-)

(63) и получишь сразу алерт от Сонаркуба

(14)

А нету __.___()?

(69) сонаркуб - тупой.
мне удобно сразу видет как ветка отрабатывает а не листать туда-сюда чтобы увидет тогда-иначе ест или нет.

(0)После названий всяких конструкций для СКД..остальное не так уж и громоздко)

(0)вообще по....х кто там чего пишет и как обзывает.
Со временем, на это не обращаешь внимание

Единственное, суржик вымораживает - ты или пиши всё на английском или всё на русском, а не половина так, половина так.

(73) ZapolnitOtchenVazhnuyuPeremennuyu() ВериИнпотентБигФанкшен()

(73) Например, всякие инструкции препроцессора мне проще написать латиницей без переключений туда-сюда: #Region, #Insert, #Delete. Ну или иметь раскладку Чистова или аналоги.

(75) а зачем переключать клавиатуру? # - Альт + 35, & - Альт + 38 и т.д.

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

(75) если вы про символы типа # и &, то лично мне удобнее набирать их как Alt+цифровой код, вместо переключения раскладки

(33) не "уроды", а "парапрограммисты".©

(75) трубоконф без переключения, по альт ставит...

(35)
"Называйте, как хотите. Но реализуйте всё функциями, возвращающими структуру с результатом"

И тут же сразу функция, возвращающая просто Булево.

"Если АСФОбщегоНазначенияКлиентСервер.ЕстьНеЦифрыВСтроке(ID) Тогда"

(0)
Венгерская нотация - да.
Длинные имена - в топку.

Но короткие имена с венгерской нотацией - нужна шпаргалка или привычка.

(20) а вы один работаете?
Я когда работал один - писал как удобнее пКонтрагент, втЗаказы.
Но когда работа коллективная и в коде каша из разных нотаций, это бесит.
Поэтому только стандарты, только хардкор

ИИчку вероятно похер на названия переменных

UID норм: ну или огрызки от гуя

c75b1c74
d552dda8

Да не пошатнись психика смертного

Топаз_Константы.ПолучитьКонстанту_ДополнительноеЗначение_Номенклатура_РабочаяСторонаКолонкиСОдностороннейИндикацией_А() ;

(84) За такое надо бить железной линейкой по пальцам, причём ребром.

Вы чо тут раздухарились. Как 1с велит, так и пишите.

(86) Мы тоже не левой ногой сморкаемся

(86) Вот когда Совместимо будем проходить - тогда напишем, как сверху велели.

(85) давайте без насилия!!!
Ваше предложение как назвать функцию выше указанную, чтобы смысл ее имени не был потерян?

(89) как поступаете когда в таком условно-постоянном виде нужно хранить массив значений (например, список складов)?

(89) А зачем в имени функции получения константы писать имя константы?

(62) поставьте себе https://github.com/otymko/phoenixbsl
и проверяйте себя в конфигураторе еще ДО сонара.
например, можно парой кликов применить к модулю "Каноническое написание ключевых слов (CanonicalSpellingKeywords)"

(88) +500

(1) я не понимаю, почему в Java можно написать getUserById , а в 1с нельзя написать ПолучитьНаименованиеНоменклатуры?

Почему?

(94) может потому что в 1с нет интерфейсов и ПолучитьНаименованиеНоменклатуры 99% что будет в ОМ рядом с еще такой же сотней ПолучитьЧтотоДругое?

(90) так как храним все в регистре сведений, то чтобы хранить списки, приходится мудрить с именами констант

Пилится функция типа получить список складов того-то сего-то.

Внутри она обращается к константе, хранящей количество значений. В цикле обращается по номерам + имена к константам. Формируется массив, возвращается.

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

Читающие функции еще создаем так чтобы они тип значения проверяли. Типа константа должна быть именно число или иной тип!

(91) искать так-то по коду программы проще по имени функции, а не имени константы
Исправлять проще

(95) "люблю" Экономистов слов, что потом код не читабелен ибо смысла у всех этих огрызков названий нет

(94) русское "Получить" сильно длинее английского get

(100) 100!

(99) у нас есть "дай"

(101) у нас есть даже такое: "давай бери"

(99) А "Пол" - не? И так понятно, что "Пол" в имени функции это не гендерная принадлежность, а "Получить" :-)

(103) Ой, фу. И будет что-то типа ПолПечФормДокРТИУ.

(94) А с каких пор джава является образцом стиля? Это уродливый язык изначально.

(105) Возьми любой другой язык.

(104) Вот так точно не надо.

(103) Лучше называть функции существительными по результату, который они возвращают. Получится примерно так:

Функция УпаковочныйЛист() Экспорт
  ТД = Новый ТабличныйДокумент;
  ...
  Возврат ТД
КонецФункции

вызов:

ТД = оКоробка.УпаковочныйЛист();
ТД.Показать();

(108) Тут непонятно, что за упаковочный лист возвращаем, может ссылку на документ или макет.

ПечатьУпаковочныйЛист() лучше

(104) ПечформаРТИУ() - почему бы и не да? (и так понятно, что РТИУ - документ, и что печформу можно по умолчанию только получить). Но все равно как-то ....

(109) можно и так
или по-венгерски:

Функция тдУпаковочныйЛист() Экспорт

(109) ПечатнаяФормаУпаковочногоЛиста() и никак иначе

(112) +1

(112) Плохо
Может быть несколько разных печформ упаклиста
Как их различать? Удобнее когда разница в конце
Поэтому объект суем вперед, и добавляем глагол для понятности:

СформироватьУпаковочныйЛистПечатнаяФормаФормат2025()

(114) +2

(114) ПечатьУпаковочныйЛист_2025()

(114) тогда так: СформироватьУпаковочныйЛист("Формат2025")

Как-то листал со скуки финский словарь, по фински программиста называют ohjelmoija, явно происходит от слов "охламон ох..ел". Это как раз про споры о длинных именах и венгерской нотации (финский и венгерский родственны, а уж про длину финских слов можно много порассуждать, нравятся они им)

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