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

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

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

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

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

(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) Полностью согласен.