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

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

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

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

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

(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 писали не долбоёбы, а венгры.
Преисполнился уважения.
Я ж не пойму по коду, что тут коллекция, а по методам, какая, мне префикс нужен, что бы это говно читать.

(114) Никаких глаголов в функциях. Глаголы - только в процедурах.
Избавляйтесь от императивной логики при функциональном подходе. Да, и кстати, функции не должны иметь побочных эффектов. Хочешь что-то менять в контексте, среде исполнения или формальных параметрах - пиши процедуру!

(119) и как ты это поймёшь в языке без строгой типизации?

"Никаких глаголов в функциях. Глаголы - только в процедурах." включу зануду. Ряд лингвистов утверждает, что неопределенная форма глагола глаголом, в строгом виде, не является... Так что можно.

(119) в нынешнем коде с 15 вызовами по 1-4 строчки действительно сложно не понять ))

(122) Не, не надо инфинитив путать с отглагольным существительным. Это другое. Типа ФормированиеУпаковочногоЛиста(). Так можно. Хотя и не нужно, если при этом возвращается не некий промежуточный "процесс", а готовая форма.

(84) а это почти как в старом добром КАМИНе. там тоже все переменные процедуры функции такой длины что в монитор не влезали))

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

(126) Можно применять "военный язык"
Вместо "Получить..." писать нечто вроде "Дай.."
И заменять длинные описания короткими "ЭтуХрень"

(127)
ВыполнитьБыстро()
ВычислитьСейчасЖе()
ЗапуститьФоновое("Задание", ОВыполненииДоложитьСюда)

(127) Спасибо. Буду пробовать повелительное наклонение глаголов
СформируйТаблицу()
УдалиФайл()
ОткройФорму()

Действительно короче и потому удобнее.
Но в случае имен свойств перестанет работать мой анализатор типа из имени в ИР, т.к. он опирается на типичные окончания неопределенных форм глаголов. Например свойство с именем "УдалитьФайл" он считает типом "Булево". А вот "УдалиФайл" уже труднее будет отличить от "КачелиФайл" и потому он спасует.

(120) как только в языке появятся лямбды и замыкания, так сразу и начнём.
Если серьёзно, ФП - это хорошо, но не надо его безумно тыкать туда, куда оно не лезет.

(129) будет диссонанс с методами платформы. Или придётся их закрыть алиасами

(130) Сделали же зачем-то модули с повторно-возвращаемыми функциями. И там побочные эффекты не нужны, и даже вредны местами. То есть ты вызвал функцию, получил значение - и можешь быть уверен только в нём, но не можешь быть уверен что она реально выполнилась.

"Спасибо. Буду пробовать повелительное наклонение глаголов" А чтоб работало и не тормозило в конце названия функции добавлять постфиксы из трех букв: "Нах" или "Б.я"...

(0) Резюме: всё подпадает под одно. Сколько людей - столько мнений.

(118) Что с чухонцев взять? Они римлян не видели.

Да простят меня люди - вот такое видел описание функции в одной самописке

Пусть будет безобразно, но однообразно. Сегодня одна культура кода, завтра - другая.

(120) а как же Запрос.Выполнить().Выбрать()

и прочие цепочки действий? оно и функция и что-то там выполняет.

(138) Это функция кого надо функция!
Это метод, это другое. И не всегда же методы что-то возвращают.

Самый бесячий косяк, что нет синонима для Новый, который должен быть как Новая

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

А вот а = Новая Структура - красиво бы было

(140) Зачем всё многообразие русского языка тащить в код? После оператора Новый указывается идентификатор типа, так что всё логично.

(140) это обсуждали. Достаточно было вместо new - назвать ключевым словом "создать"

(142) глагол "создать" требует после себя родительного падежа. Или предлагаете в конфигуратор добавить проверку правописания?

(143) "Создаём"

(144) а почему во множественном числе?

(144) Так это же ничего не меняет. Что "создать", что "создаём" требует родительный падеж.
(145) Тандем же. ) Платформа создаёт и программист немножко помогает.

(143) (144) (146) "это"

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

(148) А чем, кстати, обусловлен запрет подчёркивания?

(149) зарезервировали для себя.

(149) ну прям запрет. "пиратский кодекс - это свод рекомендаций, а не обязательных законов"

(149) Нет такого запрета. У меня вот есть обработка "АРМ_Продажи". И это более правильное название, чем АРМПродажи.

Или вот ещё:

Вместо СоздатьОбъект или Новый следовало бы использовать не ключевое слово, а спецсимвол. Типа @, который в 1с не задействован. Как создание объекта указанного класса с вызовом конструктора.

Например:

МассивФизлиц=@Массив;

Коротко и ясно!

(152) коллеги про этот пункт "3. Имена переменных запрещается начинать с подчеркивания"

А вместо двух строк декларации процедуры с указаниям места вызова

&НаСервере
Процедура ОбработатьДанныеНаСервере(ИсходныеДанные)

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

Процедура ОбработатьДанныеНаСервере(ИсходныеДанные)::Сервер

А директиву &НаСервере сделать применимой не к конкретной процедуре, а к области кода, захватывающей несколько процедур/функций, до конца модуля или до директивы, включающей иной режим.

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

(156) Для этого есть подсветка синтаксиса и выделение блоков в конфигураторе. Можно например цветом фона разделять.

(157) цвет фона, ну такое. Тут пошли по пути наименьшего сопротивления

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

(159) отдельные модули для этого должны быть, а не вот это вот всё.

(160) Ну или так, почему бы и нет? В любом случае модификатор отдельной строкой - это худшее что могло быть придумано.

(155) >А директиву &НаСервере

Логичней сделать модификаторы как в Java или C#
В одну строку со служебным словом Процедура/Функция

Ну типа public|private|protected и т.д.
Или как Экспорт в конце в 1С

Но писать в начале

Сервер Экспорт Функция ИмяФункции()
// ...
КонецФункции

Клиент Функция ИмяФункции()
// ...
КонецФункции

Но да, не нравится мне, что в 1С по сути одинаковое или похожее исторически сложилось и делается по-разному

Вот чем по сути "Экспорт" отличается от "&НаСервере" и "&НаКлиенте"?
И то, и то модификаторы для области видимости

(163) слово "Функция" необязательно. В Java/C всё функции

(162) может еще Тогда и КонецЕсли на фигурные скобки заменить и отделить оператор присваивания от оператора сравнения как == ? И процедуры как класс убрать.

Лично я был бы не против.

(165) 1С-Элемент, не?

фыва.Дай("ИмяПеременной");

возвращает значение из регистра сведений, а фыва - общий модуль

(152) не про запрет внутри, запрет на использование вначале "_индитификатора"

(168) На уровне стек-машины 1С имена переменных могут состоять из цифр и включать пробелы.

(162) Ну это уже дело вкуса, в начале или в конце. Мне больше нравится в конце, где Экспорт. Сути это не меняет.

(0)

Это нормально, если процедура "ЗаполнитьСтавкуНДСНаСервере"
не только заполняет ставкуНДС, но еще попутно удаляет многооборотную тару из тч "Товары" ?

Это кошерно с точки зрения стандартов разработки 1С ?

(171) Нет, не нормально. Надо назвать процедуру ОбработатьНаСервере()

Гуру искусства именования методов, подскажите как вы решаете дилемму "МассивВСтроку" или "СтрокаИзМассива"? Я все время по-разному называю. Не могу определиться.

(173) первый вариант. он короче

В 2016м помню я как-то будучи 1Сником пришлось переписывать обработку от чела, который уволился.
Так вот - переменные были вида _таб1, __таб1, __о1, еб**анное всё просто. Такая говнина.
Чем отличается _таб1 от __таб1??? А хз.
Еще и клиент-серверное взаимодействие не отлажено было.
Так зарефакторил, что сам свою написал в итоге за 3 недели.
Еще какие-то оптимизации сделал, в общем, стало збс.
По содержанию была сложная штука с расчетом технологической карты для производства.

(175) сразу видно, старая школа, экономия места в памяти и поэтому имена переменных a1, b12... usw.

(173) СтрокаИзМассива() правильнее, потому что не содержит неявный глагол.

(176) самое смешное что похоже он сам стал в каком-то месте путать их местами. типа с мегабайтами он экономил пару килобайт на имена переменных? ну что скажешь, гений ёпта.

(176) Извиняюсь. Вопрос для расширения кругозора. А где и когда длина имен переменных влияет на использование памяти?

(179) ассемблер знаете? Если не знаете, то не выпендривайтесь

(179) застали 8-битные Атари и Спектрумы с памятью 16к?

(35) какой кошмар. а потом смотришь в код, и не понимаешь, что там функция возвращает

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

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

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

Хотя многие 1Сники к исключениям относятся так: "В программе и так моих ошибок хватает, зачем мне их ещё специально генерировать".

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

(193) думаю в 1с это понимают. но тем не менее во всех типовых конфигурациях перед каждой функцией есть блок комментария с описанием входных и выходных параметров.
а как по-Вашему должен выглядеть код из (35)?
нужно дублировать проверку что ID это число вне этой функции перед каждым местом ее вызова?

(190) Дада
А потом заюзал такой код (с исключениями) в коде веб или http-сервиса
И получил зависания на клиентской стороне с дикими таймаутами

(195)+ Причем уй разберешься что происходит
Сервис обязан не падать
А вернуть ошибку клиенту, чтобы можно было разбираться

(180) помню как ассемблер изучал... до сих пор отличие exe файла от com помню. сидят как латинские исключения в голове у Остапа Бендера

(190) Вернуть в структуре норм, лучше передать потом структуру эту везде. Челы и ООП тут не причем.
Лучше чем рассовывать гирлянду переменных в методах.

(198) +1. Возвращать несколько значений через структуру намного красивее, чем через кучу изменяемых параметров.

(1) В большинстве популярных руководств по стилю кода (style guides) и принципам чистого кода (clean code) рекомендуется давать функциям имена-глаголы или глагольные словосочетания, так как функция — это действие.

Вот основные источники, где это прописано или широко рекомендуется:

1. Книга Роберта Мартина "Чистый код" (Clean Code)
Это классика. В главе 2 ("Meaningful Names") прямо указано:

"Methods should have verb or verb phrase names" (Методы должны иметь имена-глаголы или глагольные словосочетания).

Примеры: postPayment(), deletePage(), save().


НоменклатураНаименованиеПолучить() - так нельзя, это не глагол

(200) А процедура это не действие?

(200) В движке форума функции названы существительными, например, Topic.author() - функция возвращает автора ветки.

(200) Да, читал.

Многие рекомендуют эту книгу. Но есть нюанс. Книга была написана в 2010 году. Вот уже 15 лет как...

Возможно, пришло время написать другую книгу. Актуальную!

(202) это похоже больше на property, то есть свойство. Ожидаешь еще наличие getAuthor и setAuthor, но это не тот случай

(203) Актуальная книга скоро будет такая: "Называйте переменные как хотите, ИИ похрену на это разберётся"

(205) Лет через 10 программист даже не будет знать, что такое переменная и не будет думать, как эту сущность обозвать.

(206) Вот это прогноз! А что будет? Мыслеформы?

(206)

Вспоминается "История про один байт"

https://habr.com/ru/articles/27055/

(207) Промт вида "Необходимо спарсить с сайта mista.ru все сообщения пользователя с ником Гипервизор, игнорировать сообщения где это не ник пользователя, а упоминание его или аналогичный нику текст"

(198) (199) Многим не нравится что типизации нет
И обязательность не проверяется само

Может доработать структуры, добавив типизацию и нечто вроде ПроверитьЗаполнение() встроенное для них

(210) А что, в параметрах есть типизация?

(210) Вот тоже не понимаю не нравится? Ну организуй сам в своем коде.
Это наследие программирования на других языках и обучения на тех языках где строгая типизация, страдал этим только в момент входа в 1С. А потом проблемы отсутствия типизации всплывают раз в год, и то когда делаешь что-то нестандартное.  Ну и зачем оно тогда?

(197) к сожалению, помню уже смутно. MZ... размеры сегментов, адрес точки входа, прочие данные в заголовке.
Изучал ибо попалась мне антология выпусков фидошного журнала инфектед войс. Учился в лабораторных целях писать вирусы.
Учился долго и упорно. Разумеется, ни один вирус пределы моего компа не покинул ))
вся эта история закончилась как-то одномоментно )) в одном из выпусков был листинг исходника одного из вариантов Чернобыля. Как раз тот, который МБРку затирает. Решил прогнать в отладчике. Опять же лабораторных целях. Скомпилил, поизучал и... забыл..... Как сейчас помню... было утро субботы. Горячий кофе, желание поковырять диплом, который через 2 недели на рецензию сдавать... BOOT DISK FAILURE ))))))) Хорошо, что был распечатан черновик диплома.

ИИ ответил так и я согласен с этим.
Для 1С-практики лучше глагол + сущ.: ПолучитьНоменклатуру(). Такой порядок читается естественно и соответствует типовым стилям (действие → объект)

Те имена, которые ты сам используешь - всегда хороши.

ЭтоБаранов = СтрНайти(ПараметрыСеанса.ТекущийПользователь.Наименование, "Баранов ") > 0;
Если ЭтоБаранов Тогда
   Предупреждение("Доступ запрещён!");
   Отказ = Истина;
   Возврат;
КонецЕсли;

https://govnokod.ru/1c
не благодарите ))

(14) 👍
Я всегда "м" пишу в имени переменных уровня модуля - хоть что-то.
Вообще, плохо, что по имени нельзя понять - то ли это переменная (локальная или уровня модуля), то ли реквизит объекта, то ли реквизит формы, то ли параметр процедуры.

(214) такие стили именований могут быть наследством от англоязычных (западных) стилей, определяемых в т.ч. менталитетом и строением языка.
.
когда я открою какую-нибудь типовую и надо найти, как работают типовые с номенклатурой - я в первую очередь буду искать "номенкл", а не "получить"/взять/сложить/итд.

Да, сложилась практика отглагольных форм. но что-то я последнее время, когда много процедур и функций начал "группировать" по принципу "Объект" -> "Что с ним делаем"...

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

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

(221) 🔥