Добрый день коллеги! Не секрет, что костыли исправляющие поведение платформы проникли даже в БСП, см. ОбщегоНазначения.ЗначенияРеквизитовОбъекта. Поделитесь своими "любимыми" костылями.

(194) Это так и было задумано :) Он поэтому и не ГУИД.

(196) 1С ввела в заблуждение названием, надо было назвать ИногдаУникальныйИдентификатор

(197) Не иди по стопам 1с, не вводи в заблуждение окружающих.
Он уникальный. В пределах таблицы.

(198) ок, УникальныйИдентификаторВПределахТаблицы

(185) Скинь мне тоже пож-та (или в Телегу)

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

Коллеги не стесняйтесь, делитесь любимыми костылями.

(202) Обертка для менеджера записи со свойствами как у набора записей (обменданными.загрузка и доп. свойства)

(203) это круть :)

(203) не могу представить зачем это

(205) Наглядность и краткость кода (как у МЗ) с использованием указанных выше двух возможностей, доступными только НЗ

*доступных

(201) Права...  сколько я повидал РС с названиями типа "Доп.права", "Динамические права" и т.д. с разным радиусом кривизны реализации.

(206) ясно, я так привык к НЗ, глаз уже замылился, лет 5 наверное РЗ не использую

(209) очепятка РЗ = МЗ

а собственные индексы, привет соглашению с 1С, кто нибудь использует?

(154) и что, что на жаве?

(138) на жаве говнокодить можно, но делать это чуть сложнее, чем на 1с

(212) "язык должен быть серьёзным, без лишних волностей"
(с) Не Я

продолжу, флюент интерфейс через обработки, см. инфостарт

(140) ИМХО, дело не в нише, переваривающей говнокод. Платформа 1с это уже сам по себе некий стандарт. Ни один рукожом не сможет заставить справочник перестать быть справочником. Притащи с улицы любого 1сника, ткни пальцем в любой объект в дереве объектов конфигуратора, и этому 1снику будет понятно предопределенное поведение этого объекта, для чего и как он может быть использован. В то же время, на том же FoxPro городили кто во что горазд. Наверно поэтому FoxPro так и не доросла до серьёзных систем, застряв на уровне наколенных нетленок. Фузинцы решили повторить подвиги FoxPro, во что это вылилось сам видел: у них справочник это недосправочник-недоотчет-недорегистр в одном гранёном стакане. В то же самое время, на 1с такое нарукожопить сложно. Вот поэтому 1с и держится прочно в своей нише - у платформы большой запас прочности

(86) (87) используется в фоновых заданиях, разумеется в основном потоке я не использую эту функцию.

Замечательный костыль в БСП: ПроверитьПараметр.

Синтаксис

Процедура ПроверитьПараметр(Знач ИмяПроцедурыИлиФункции, Знач ИмяПараметра, Знач ЗначениеПараметра,
    Знач ОжидаемыеТипы, Знач ОжидаемыеТипыСвойств = Неопределено) Экспорт
Параметры

   ИмяПроцедурыИлиФункции - Строка - имя процедуры или функции, параметр которой проверяется.
   ИмяПараметра - Строка - имя проверяемого параметра процедуры или функции.
   ЗначениеПараметра - Произвольный - фактическое значение параметра.
   ОжидаемыеТипы - ОписаниеТипов, Тип, Массив, ФиксированныйМассив, Соответствие, ФиксированноеСоответствие - тип(ы)
       параметра процедуры или функции.
   ОжидаемыеТипыСвойств - Структура - если ожидаемый тип - структура, то
       в этом параметре можно указать типы ее свойств.

У меня не типовая, с БСП близко не знаком.

в БСП, как в Греции, всё есть

ЭтоУникальныйИдентификатор
Проверяет, является ли строка уникальным идентификатором.
В качестве уникального идентификатора предполагается строка вида
"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", где X = [0..9,a..f].
Синтаксис

Функция ЭтоУникальныйИдентификатор(Знач Значение) Экспорт
Параметры

  Значение - Строка - проверяемая строка.
Возвращаемое значение

  Булево - Истина, если переданная строка является уникальным идентификатором.

(218) С принципе, мне нравится твоя философия. "Язык + костыли = программа". Как-то так оно в жизни и происходит.

(220) Костыли неотъемлемая часть программы, невозможно всё впихнуть в язык. Но когда использование костыля становится массовым, мне кажется, что пора задумываться о включении его в язык. Если посмотреть синтакс-помощник можно найти методы которые не понятно кому нужны. Но они есть, а то что используется во всех типовых почему то в язык не включено. Где логика?

(221) логика в том что развитие языка идёт по плану.
Сначала появляются библиотеки, потом они становятся частью языка. Как это было например со строковыми функциями например

(218)(219) не понятно, почему ты подобные библиотечные функции считаешь костылями? Например, ЭтоУникальныйИдентификатор() очень полезная функция при интеграции со сторонними системами

(223) Костыль, в данном случае, то что могло быть в платформе. Но этого нет. Если бы это было разово разработано, каким то левым разработчиком, для узкой цели, то бог с ним. Но это применяется массово. Вот я не использую, БСП, сам виноват - знаю, мне нужно или самому писать что-то такое, либо искать написанной другими. Я и написал, через попытку.

(221) Частично так и происходит. Какие-то функции, ставшие стандартными в БСП, были впоследствии реализованы в языке. Вспомнить хотя бы ЗначениеЗаполнено, СтрШаблон и т.п. Но это касалось только очень простых и действительно очень массово и постоянно используемых функций.
(244) Вопрос в том, стоит ли в стандартную библиотеку языка тащить все полезные функции? Однозначно нет. Вот ты говоришь, что проверка на уникальный идентификатор применяется массово. Вопрос в том - насколько массово? Я вот лично ни разу не проверял. И почему-то мне кажется, что я не одинок. Тоже самое ПолучитьРеквизиты() - применяю чрезвычайно редко. Обычно удается писать так, чтобы получать все запросами одновременно с кучей других данных. А в простых и понятных случаях - смело работаю через точку.
А вот ЗначениеЗаполнено() и СтрШаблон() - другое дело. Это нужно всем и каждому и нужно постоянно.

Я могу понять, когда в платформу добавляют нечто, что не используется массово, но что сложно или неудобно реализовать на языке 1С, если это вдруг понадобится. Тут есть резон. А какой смысл включать в язык что-то, что массы каждый день не юзают, но что легко реализуется при необходимости и так?

(226) ЗначениеЗаполнено так же легко реализуется

(227) Зато оно пригождается в каждой второй функции, кто бы и что бы не писал.

Недавно такое в УТ видел:

Функция ВремяОжиданияИтерации(НомерИтерации)
  
    Если НомерИтерации < 15 Тогда
        ВремяОжидания = 1;
        Для НомерИтерации = 2 По НомерИтерации Цикл
            ВремяОжидания = ВремяОжидания * 1.4;
        КонецЦикла;
    Иначе
        ВремяОжидания = 120;
    КонецЕсли;
  
    Возврат ВремяОжидания;
  
КонецФункции

вроде переписали по человечески

интересно здесь вот это:
Для НомерИтерации = 2 По НомерИтерации Цикл
(ну, кроме того, что все это в принципе говнокод)

Да, нет смысла тянуть ТЧ при обращении к реквизиту ссылки

(39) О, я себе недавно такое писал)

(54) Ага, давайте лучше размажем простецкую конструкцию на 5 строк...

(57) Достаточно просто не получать табличные части у ссылок.. Так извращаться ради реквизитов - оверхед

Где голосовалка?

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

Где ++?
Где лямба функции?
LINQ бы не помешал

С переходом на 8.3 могли бы добавить методы, которые конвертят ТЗ в массивы и наоборот.

Но нет, верх всего происходящего - это долгожданное появление таких функций как СтрШаблон.
Нет слов.

(230) Почему говнокод?

(232) потому что этот код не работает (всегда одна итерация цикла), а также потому что возведение в степень есть в платформе.

но знали ли вы, что предел цикла Для вычисляется один раз? и при этом после присвоения начального значения?

(233) Если заменить переменную счетчика на другую, то имеет право на жизнь.
По (230) я подумал, что сама идея - говнокод.

(231) "С переходом на 8.3 могли бы добавить методы, которые конвертят ТЗ в массивы и наоборот"

Так это же есть в БСП. К тому же не самая распространенная задача. В большинстве случаев не требуется гнать никакую табличку на клиент

ООП - сомнительная необходимость в 1с. Сколько я ни спрашивал у апологетов ООП, никто так и не сумел привести примера надобности оной в 1с

(236) В большинстве случаев и регистры расчета не нужны. Давайте их в БСП вынесем

(237) Достаточно будет инкапсуляции (да, я только что гуглил основные принципы). В наследовании основного смысла нет, ну а про инкапсуляции вы и сами понял xd

Пример:
Хочу сделать объект, который будет обрабатывать мою таблицу значений. Первый метод - возвращает сортированную, второй - конвертит в массив, и т.д.

Текущие варианты реализации:
1. На ОФ можно сделать модули в виде форм. Как тиражное решение - никуда не годится. Крайне неудобно
2. На УФ? Ну на клиенте можно те же формы. А сервер?

Инициализировать всё нужное в структуру, а потом гонять её по функциям, которые будут разбросаны вперемешку с основным кодом?
https://i.ytimg.com/vi/HcfHBgUTn7I/maxresdefault.jpg

(238) "про инкапсуляции вы и сами понял" -> "про полиморфизм вы и сами поняли"

(238) инкапсуляция это не какие-то там возможности программирования. Это прежде всего принципы написания кода. Инкапсуляция была придумана ещё задолго до ООП, только пользовались ей лишь опытные разработчики, и держалась она на дисциплине при написании кода. В 1с есть всё необходимое, чтобы инкапсулировать алгоритмы. Ты можешь создать общий модуль, добавить в него экспортную процедуру, вспомагательные процедуры сделать не экспортными, и будет твой алгоритм инкапсулирован в самом полном смысле этого слова. А полиморфизм при динамической типизации, как мы уже выяснили, скорее источник проблем, чем благо

(240) Инкапсуляция - это в первую очередь про данные. Попробуй данные в модуль запихнуть )

(241) не-а, инкапсуляция это про скрытие деталей реализации. Скрытие данных тут скорее побочный бонусный эффект

(0) СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(...) - там, где СтрШаблон недоступен.

(216) "Платформа 1с это уже сам по себе некий стандарт"
"В то же время, на том же FoxPro городили кто во что горазд"
Потому что 1с - это фреймворк, а фокспро - БД.

(240) Мне лично в модулях нет нравится то, что из служебных модулей типа КлиентСервер и ПовтИсп их "потроха" торчат наружу в виде служебного интерфейса и приходится пользоваться соглашением, что на клиенте используем только модуль с припиской Клиент, на сервере - только вообще без приписок.
Также торчат наружу всякие подписки на события и обработчики регл. заданий.
Ну и обработчики оповещений тоже.

Так что инкапсуляция получается далеко не полной.

(243) эти функции, кстати, не равнозначны - СтрШаблон падает при отсутствии локализованной строки, а ПодставитьПараметрыВСтроку() - не падает.

(244) Фокс - это не БД. Это СУБД.

(247) Строго говоря там логика представлений тоже была и достаточна развитая. Ну и много чего еще было. Так что все-таки это ближе к платформе было. Только она с внешними SQL дружила где-то на уровне Delphi, а когда SQL стал де факто стандартом в отрасли, все преимущества сошли на нет и Microsoft логично сделала ставку на .Net, похоронив Foxpro.

(248) Точнее даже так: на .Net и Axapta, причем их начали сильно сближать друг к другу, X++ используемый в Axapta сейчас очень похож на C#.

(178)Это самое крутое что я видел за последние 3 года, да блин я с 7.7 таких хаков не встречал. Это просто песня!

(249) Бро, у тебя во Фузине костыли есть? Делись :)

(241) (242) согласен с ДенисЧ
толку от инкапсуляции реализации, без возможности завернуть в нее данные (состояние объекта) - не много

(251) В самой фузине или в решениях на фузине?

(253) в решениях

(247) не может быть такого)

(254) Ну то что сходу могу вспомнить:
При расчете себестоимости она выделяется в новый цикл в транзакции, а потом разбивается на итерации.
https://github.com/lsfusion-solutions/mycompany/blob/c2ca9254b4dce33988073b5b1d7ee105029561a0/src/main/lsfusion/inventory/ledgers/CostLedger.lsf#L47

Плюс например в ERP очень сильно намудрили с видами цен, замкнув все на одну функцию цена от любого вида цены (а видов цен там десятки, а то и сотни). Соответственно если начать компилировать из этого один запрос он получится очень большим. В итоге иногда делают выверты с событиями на изменения видимой части таблицы:

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

WHEN LOCAL FORMS userOrder (SET([ VIEW userOrder.sts](Stock stock, Sku sku)) AND currentUserOrderUserOrder() = UserOrder o) OR     
                        ((CHANGED(priceDateTime(o)) OR    
                          CHANGED(priceListType(o)) OR    
                          CHANGED(agreement(o))) AND [ VIEW userOrder.sts](stock, sku)) DO     
    updateViewPrice(sku, stock, o);    
;    

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

updateViewPrice (Sku sku, Stock stock, UserOrder userOrder)  {
    FOR PriceListType pt = priceListType(userOrder, sku) AND (Stock st = IF overPriceStockUser(userOrder) THEN overPriceStockUser(userOrder) ELSE stock) AND stock IS Stock AND DATETIME dt = priceDateTime(userOrder) NOINLINE (pt) DO
        viewPrice(sku, stock, userOrder) <- prevPriceB(pt, sku, st, dt);
}

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

Ну и мелочи которые недоделали. Например отсутствие вывода типа из равенства (то есть PriceListType в примере платформа могла бы сама определить), ну и в таком духе из чего иногда получаются java проблемы вроде Борщ борщ new Борщ.

Процедура ПриЧтенииСозданииНаСервере()
{


}

(257) в чем костыльность? простите я не понял

(256) интересно, разработчики платформы так же отслеживают костыли?

(258) В том, что практически в каждой форме объекта эта конструкция нагорожена. Просто отсутствует удобный обработчик формы для заполнения реквизитов формы зависящих от данных объекта (вне зависимости от того новый он или нет).

(260) меня фигурные скобки сбили с толку, типовые конфигурации?

(259) Интересный вопрос. Потому как природа человека такая что если он нашел workaround, он часто не то что не зарепортит, а наоборот будет ходить довольный какой он умный. :) Думаю при разработки типовых в 1С та же фигня.

(244) вообще фокспро СУБД, но использовалась она для тех же целей, что и 1с

(252) ну как это нет толку? Помнишь эпопею со ставками НДС в конце прошлого года? Добавилось новое значение перечисления СтавкиНДС, а меняли код в тыще мест. Этого не было бы, если бы расчет размера НДС был инкапсулирован в отдельном модуле. Тогда обошлось бы исправлением нескольких строк кода

(264) это и без ООП можно реализовать

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

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

(265) естественно. Я про то и пишу, что инкапсуляция возможна и без ООП

(266) функциональщина и наследование / полиморфизм (а это основа ООП) это строго говоря две перпендикулярные вещи.

(267) это уже вопрос написания кода и запросов. Достаточно оставить болезненную, но популярную манеру делать вычисления в запросе, и всё будет тип-топ. В отчетах на СКД можно подтянуть глобальную функцию, в простых запросах делать все расчеты при выборке

(269) речь про то что ооп - это стейт, а функциональщина - это как раз отсутствие стейта

(271) интересная статья на эту тему https://habr.com/ru/post/479238/

(235) сама идея делать это циклом - тоже говнокод

(270) текст запрос можно собирать

Выжимка из https://habr.com/ru/post/479238/: Отсутствие эффектов это единственное требование, которое нужно соблюдать, чтобы программа была функциональной.

(275) ну так не пиши инчего в базу тогда

(274) это как раз bad practice

(276) там решается через DI  и проброса объекта записывающего в базу

(278) нет, это не ФП.

(277) коллеги подсказывают, что в ЗУПе применяется очень активно сбор текста запроса

(280) зуп - это воообще сборник лютых bad practice

(279) ну так сам объект пишущий не фп, а все останое фп

(280) ну это не значит, что надо делать также

(280) Опыт подсказывает, что модули ЗУПа писали крайне упоротые наркоманы.

(273) А возведение в степень - не цикл?

(285) не всегда, и что там в процессоре при этом происходит - хз вообще. Факт в том, что на языке платформы писать 5 операторов вместо одного - неправильно.

(284) Дык дело не в конфе.
Разработчики ЗУП для того что бы разрабатывать должны быть упороты так же как и законотворцы, если не дунуть то ничего не получится (Амаяк Акопян)

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

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

По сабжу. Не всё, что "могло бы быть в платформе", должно быть непременно в платформе. Например, ПроверитьПараметр() - вполне норм.

(289) Надеюсь, в фузине это не проблема )

(289) ПроверитьПараметр - это было бы не нужно, если бы можно было типизировать параметры методов.

а что значит ПроверитьПараметр?

(292) см (218)

(291) Нужно. Параметры бывает нужно проверять не только на тип. Но в слабо типизированных языках — ещё и на тип. Это нормально.

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

(294) хотел написать про то что было бы хорошо если бы платформа проверяла тип, но передумал