Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) Здравствуйте !
При объектном чтении ( Например, ДокументСсылка.Номер )
из СУБД считываются не только реквизиты объекта, но (если есть)
и все табличные части и все реквизиты-хранилища, чтение происходит в транзакции.
Представляете, насколько это более затратно для СУБД, чем запрос
Выбрать ДокументПоступления.Номер
ИЗ Документы.ПоступлениеТоваровУслуг КАК ДокументПоступления
Где ДокументПоступления.Ссылка = &Ссылка
Поэтому в современных типовых программах разработчики не используют объектное чтение.
При объектном чтении ( Например, ДокументСсылка.Номер )
из СУБД считываются не только реквизиты объекта, но (если есть)
и все табличные части и все реквизиты-хранилища, чтение происходит в транзакции.
Представляете, насколько это более затратно для СУБД, чем запрос
Выбрать ДокументПоступления.Номер
ИЗ Документы.ПоступлениеТоваровУслуг КАК ДокументПоступления
Где ДокументПоступления.Ссылка = &Ссылка
Поэтому в современных типовых программах разработчики не используют объектное чтение.
(5) хорошо, принял.
но вы ориентируетесь на то, что якобы знаете как работает платформа.
а вы уверены, что разработчики платформы заложили именно такой "затратный по производительности" механизм объектного извлечения данных?
то есть по сути, мне нужен ИНН контрагента, я прописал Контрагент.ИНН. А они заложили в платформе, что тащится весь справочник Контрагентов со всеми табличными частями? Может быть, стоит им написать, чтобы они улучшили свой алгоритм и не извлекали лишнего?
но вы ориентируетесь на то, что якобы знаете как работает платформа.
а вы уверены, что разработчики платформы заложили именно такой "затратный по производительности" механизм объектного извлечения данных?
то есть по сути, мне нужен ИНН контрагента, я прописал Контрагент.ИНН. А они заложили в платформе, что тащится весь справочник Контрагентов со всеми табличными частями? Может быть, стоит им написать, чтобы они улучшили свой алгоритм и не извлекали лишнего?
(11) Это известная проблема, по ней много публикаций.
Я проверял в профайлере, всегда работает одинаково.
Разработчики платформы хотели бы что-то изменить,
но их связывает обратная совместимость и прочие обязательства.
Я проверял в профайлере, всегда работает одинаково.
Разработчики платформы хотели бы что-то изменить,
но их связывает обратная совместимость и прочие обязательства.
(11)
при объектном чтении, все таки, возможно, проблема не в том, что тащатся все реквизиты с табличными частями, а скорее в случаях, когда пишут такой код:
В этом случае, вроде как выполняется три запроса, а при использовании функции ОбщегоНазначения.ЗначениеРеквизита() - это можно сделать за одно обращение к БД. Хотя тут, возможно, используется кэш, но это неточно.
при объектном чтении, все таки, возможно, проблема не в том, что тащатся все реквизиты с табличными частями, а скорее в случаях, когда пишут такой код:
НоваяСтрока = ТаблицаКонтрагенты.Добавить();
НоваяСтрока.ИНН = КонтрагентСсылка.ИНН;
НоваяСтрока.КПП = КонтрагентСсылка.КПП;
НоваяСтрока.Наименование = КонтрагентСсылка.Наименование;
В этом случае, вроде как выполняется три запроса, а при использовании функции ОбщегоНазначения.ЗначениеРеквизита() - это можно сделать за одно обращение к БД. Хотя тут, возможно, используется кэш, но это неточно.
(11)
а вы уверены, что разработчики платформы заложили именно такой "затратный по производительности" механизм объектного извлечения данных?
(11)
Добавили бы в конфигуратор для всех реквизитов признак "Вызов через точку" - чтобы не тащить все остальные поля при такой конструкции "Контрагент.ИНН".
А они заложили в платформе, что тащится весь справочник Контрагентов со всеми табличными частями? Может быть, стоит им написать, чтобы они улучшили свой алгоритм и не извлекали лишнего?
Добавили бы в конфигуратор для всех реквизитов признак "Вызов через точку" - чтобы не тащить все остальные поля при такой конструкции "Контрагент.ИНН".
// Занудство ON
(5) Не лучший пример (получение поля "номер"). Основные поля прикладных объектов кэшируются без чтения всего объекта. При их получении через точку весь объект не будет считан. А вот ДокументСсылка.Организация, считает весь объект.
// Занудство OFF
(5) Не лучший пример (получение поля "номер"). Основные поля прикладных объектов кэшируются без чтения всего объекта. При их получении через точку весь объект не будет считан. А вот ДокументСсылка.Организация, считает весь объект.
// Занудство OFF
Кроме этого, метаданные (Справочники, Документы, Регистры…) в дереве необходимо сортировать. Так гораздо аккуратнее. Реквизиты объектов можно оставить без сортировки.
Не соглашусь. Очень удобно, когда новые объекты конфигурации добавляются в конец списка. В таком случае, во-первых ты имеешь представление о том, что делают другие участники команды, во-вторых часто возникает необходимость обратиться к объектам, добавленным пару месяцев назад, тобой или кем-то другим, при этом уже не помнишь или не знаешь точное название этих объектов. В этом случае просто открываешь список документов, бежишь глазами вверх и быстро находишь нужный объект
(2) оба варианта имеют право на жизнь.
для конечного продукта и конечного потребителя - лучше отсортировать, и тогда - когда внедренец будет добавлять свои объекты - он будет различать , где типовые (по поставке продукта), а где его.
в вашем случае - при разработке продукта и тем более в команде удобно видеть новые создаваемые объекты, поэтому сортировать не целесообразно.
Сортировка должна происходить между процессом разработки и продажей продукта - получается промежуточным этапом.
для конечного продукта и конечного потребителя - лучше отсортировать, и тогда - когда внедренец будет добавлять свои объекты - он будет различать , где типовые (по поставке продукта), а где его.
в вашем случае - при разработке продукта и тем более в команде удобно видеть новые создаваемые объекты, поэтому сортировать не целесообразно.
Сортировка должна происходить между процессом разработки и продажей продукта - получается промежуточным этапом.
(2)
Не соглашусь с "не соглашусь".
При обновлении этот принцип "новые объекты конфигурации добавляются в конец" - херится напрочь. В итоге - в конце списка тупо каша из добавленных кастомных объектов и новых объектов типовых..
Если требуется систематизировать работу с кастомными объектами - лучше их выделять в отдельную подсистему/подсистемы.
Не соглашусь с "не соглашусь".
При обновлении этот принцип "новые объекты конфигурации добавляются в конец" - херится напрочь. В итоге - в конце списка тупо каша из добавленных кастомных объектов и новых объектов типовых..
Если требуется систематизировать работу с кастомными объектами - лучше их выделять в отдельную подсистему/подсистемы.
(0) 5 минут думал, в чем смысл листинга? красной рамкой и чертой - выделены фрагменты, которые не стоит использовать, зеленой рамкой - видимо, улучшенный вариант.
Оригинальная подача материала - удобно для восприятия, затратно по времени подготовки.
Как реализовали ?
Оригинальная подача материала - удобно для восприятия, затратно по времени подготовки.
Как реализовали ?
(0) Коллеги, я вот учился в 2008 году по книге Радченко, где было написано, что извлекать данные можно объектно и по запросу. Не было оговорок про производительность того или иного способа. Наоборот, местами было удобнее использовать объектное обращение к переменным: ПолучитьПоследнее() по регистру сведений - например, цену или курс доллара.
А сейчас, цену не стоит так извлекать? Что потащится из базы при использовании такой конструкции? вроде как вся запись по отбору регистра сведений....
А сейчас, цену не стоит так извлекать? Что потащится из базы при использовании такой конструкции? вроде как вся запись по отбору регистра сведений....
(25) Добрый день, различие будет, если прочитать набор записей внутри внешней транзакции (при проведении) и потом записать. Разделяемая управляемая блокировка (накладывается при Набор.Прочитать()) превратится в исключительную (Набор.Записать()), а это потенциальный deadlock.
А с объектным чтением документа с табличными частями почему то не воспроизвелось, нет и все разделяемой управляемой блокировки. ))
А с объектным чтением документа с табличными частями почему то не воспроизвелось, нет и все разделяемой управляемой блокировки. ))
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание задачи - опционально>
2.2. Перем НоваяПеременная1, НоваяПеременная2;
//- ПРЕФИКС <Фамилия И.О. разработчика>
2.2. Перем НоваяПеременная1, НоваяПеременная2;
//- ПРЕФИКС <Фамилия И.О. разработчика>
Модный нынче Git еще не освоили?
Этот и последующие образцы для комментирования - разве не дурной тон по тому же Макконнеллу? Представьте один типовой модуль, в который раз в месяц один из разработчиков вносит изменения. Этот модуль уже через год-два превратится в зеленую лужайку из-за комментариев, где кое-где встречаются конструкции языка. Такой "зеленый" модуль усложняет чтение самого кода.
И еще зачем использовать "ПРЕФИКС_" в добавлении ко всем объектам, реквизитам, функциям и так далее? Вот никогда не понимал, почему так делают. Мое предположение, что это было крайне важно в 7.7 (я с ней не работал), и программисты старой закалки перетащили это в 8.х, где это не приносит существенной пользы.
(33)
Вот если модуль типовой то как раз пусть вносит комментарии, кто, когда и что изменял или дополнял. Если же модуль его собственный то тут уже по ситуации.
тот и последующие образцы для комментирования - разве не дурной тон по тому же Макконнеллу? Представьте один типовой модуль, в который раз в месяц один из разработчиков вносит изменения. Этот модуль уже через год-два превратится в зеленую лужайку из-за комментариев, где кое-где встречаются конструкции языка. Такой "зеленый" модуль усложняет чтение самого кода.
Вот если модуль типовой то как раз пусть вносит комментарии, кто, когда и что изменял или дополнял. Если же модуль его собственный то тут уже по ситуации.
(34)
ФИО разработчика и когда внесено изменение - это задача системы контроля версий.
т если модуль типовой то как раз пусть вносит комментарии, кто, когда и что изменял или дополнял. Если же модуль его собственный то тут уже по ситуации.
ФИО разработчика и когда внесено изменение - это задача системы контроля версий.
(33) Здравствуйте !
есть мнение, что такие комментарии - нелепые и что EDT и GIT вскоре решат эту проблему.
Но пока сам не пробовал. Мы используем именно такие комментарии.
Это помогает при обновлении и поддержке. Возможно, это не эталон.
есть мнение, что такие комментарии - нелепые и что EDT и GIT вскоре решат эту проблему.
Но пока сам не пробовал. Мы используем именно такие комментарии.
Это помогает при обновлении и поддержке. Возможно, это не эталон.
Добрый день
Спасибо за статью, сам все хочу приобрести эту книгу, но никак руки не доходят. Вы говорите, что она хорошо подходит и для 1С?
Вопросы, замечания по тексту:
1. ЗначениеРеквизитаОбъекта - а разве можно передавать структуру, чтобы получить реквизит реквизита? У вас какая-то доработанная версия?
2. Честно говоря, мне не нравится как 1С выравнивает многострочные логич выражения. Я бы их ставил на уровне первого Если, а не вложенного кода. Я один такой?
3. "аргументы функции (процедуры) при возможности сохранять в структуре значений, которая будет единственным аргументом" - вот что-то никак не могу это принять. Да, для кастомизации это круто, можно спокойно добавлять новый параметр, не переписывая везде интерфейс. Но вот для понимания и читабельности... Что, кому-то это удобнее? Тут становится понятно только по описывающему комментарию перед функцией. Но ведь рядом же написана мысль, что хороший код в комментах не нуждается.
4. "Модули форм оформляются через области, используя стандартные и, при необходимости, свои" - список, что дальше, это официальный, из ИТС? Не встречал его раньше.
P.S. Сама подача материала не очень понравилась. Я не приветствую клиповость, особенно для статей на такую серьезную тему. Лучше текст почитать.
С другой стороны, может вам здесь как раз не хватило этой клиповости. Вы в начале написали, я ждал какой-то яркой картинки, а в итоге не сразу заметил, что картинки вообще меняются. Если уж идти в этом направлении, то должны быть стрелки, другие яркие элементы для привлечения внимания, какая-то динамика.
Спасибо за статью, сам все хочу приобрести эту книгу, но никак руки не доходят. Вы говорите, что она хорошо подходит и для 1С?
Вопросы, замечания по тексту:
1. ЗначениеРеквизитаОбъекта - а разве можно передавать структуру, чтобы получить реквизит реквизита? У вас какая-то доработанная версия?
2. Честно говоря, мне не нравится как 1С выравнивает многострочные логич выражения. Я бы их ставил на уровне первого Если, а не вложенного кода. Я один такой?
3. "аргументы функции (процедуры) при возможности сохранять в структуре значений, которая будет единственным аргументом" - вот что-то никак не могу это принять. Да, для кастомизации это круто, можно спокойно добавлять новый параметр, не переписывая везде интерфейс. Но вот для понимания и читабельности... Что, кому-то это удобнее? Тут становится понятно только по описывающему комментарию перед функцией. Но ведь рядом же написана мысль, что хороший код в комментах не нуждается.
4. "Модули форм оформляются через области, используя стандартные и, при необходимости, свои" - список, что дальше, это официальный, из ИТС? Не встречал его раньше.
P.S. Сама подача материала не очень понравилась. Я не приветствую клиповость, особенно для статей на такую серьезную тему. Лучше текст почитать.
С другой стороны, может вам здесь как раз не хватило этой клиповости. Вы в начале написали, я ждал какой-то яркой картинки, а в итоге не сразу заметил, что картинки вообще меняются. Если уж идти в этом направлении, то должны быть стрелки, другие яркие элементы для привлечения внимания, какая-то динамика.
(48) Здравствуйте !
1. Да, попробуйте сами. У нас версия БСП не новая.
2. Возможно, 1С выравнивает многострочные логич выражения не лучшим способом.
я исходил из девиза "Безобразно, но однообразно"
3. Использовать структуру как аргумент - это тренд производителя. В этом что-то есть.
4. Список областей не входит в стандартные требования. Но применяется часто.
5. По теме много серьезных статей. Хотелось как-то выделиться. Стрелочки наверное добавлю.
1. Да, попробуйте сами. У нас версия БСП не новая.
2. Возможно, 1С выравнивает многострочные логич выражения не лучшим способом.
я исходил из девиза "Безобразно, но однообразно"
3. Использовать структуру как аргумент - это тренд производителя. В этом что-то есть.
4. Список областей не входит в стандартные требования. Но применяется часто.
5. По теме много серьезных статей. Хотелось как-то выделиться. Стрелочки наверное добавлю.
(49) 1:
Попробовал пример, как у вас, в УТ 11.4, выдало ошибку:
Зато работает такой способ: ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "Контрагент.ИНН")
Попробовал пример, как у вас, в УТ 11.4, выдало ошибку:
{ОбщийМодуль.ОбщегоНазначения.Модуль(258)}: Поле объекта не обнаружено (Структура)
Возврат Результат[СтрЗаменить(ИмяРеквизита, ".", "")];Зато работает такой способ: ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "Контрагент.ИНН")
(54) у меня УТ 11.4.2.144 Ниже описание функции ЗначенияРеквизитовОбъекта. Седьмая сверху строка - тип Структура. Но возможно, я неправильно написал на картинке синтаксис.
// Параметры:
// Ссылка - ЛюбаяСсылка - объект, значения реквизитов которого необходимо получить.
// - Строка - полное имя предопределенного элемента, значения реквизитов которого необходимо получить.
// Реквизиты - Строка - имена реквизитов, перечисленные через запятую, в формате
// требований к свойствам структуры.
// Например, "Код, Наименование, Родитель".
// - Структура, ФиксированнаяСтруктура - в качестве ключа передается
// псевдоним поля для возвращаемой структуры с результатом, а в качестве
// значения (опционально) фактическое имя поля в таблице.
// Если ключ задан, а значение не определено, то имя поля берется из ключа.
// - Массив, ФиксированныйМассив - имена реквизитов в формате требований
// к свойствам структуры.
// ВыбратьРазрешенные - Булево - если Истина, то запрос к объекту выполняется с учетом прав пользователя, и в случае,
// - если есть ограничение на уровне записей, то все реквизиты вернутся
// со значением Неопределено;
// - если нет прав для работы с таблицей, то возникнет исключение.
// - если Ложь, то возникнет исключение при отсутствии прав на таблицу
// или любой из реквизитов.
//
// Возвращаемое значение:
// Структура - содержит имена (ключи) и значения затребованных реквизитов.
// - если в параметр Реквизиты передана пустая строка, то возвращается пустая структура.
// - если в параметр Ссылка передана пустая ссылка, то возвращается структура,
// соответствующая именам реквизитов со значениями Неопределено.
// - если в параметр Ссылка передана ссылка несуществующего объекта (битая ссылка),
// то все реквизиты вернутся со значением Неопределено.
//
Функция ЗначенияРеквизитовОбъекта(Ссылка, Знач Реквизиты, ВыбратьРазрешенные = Ложь) Экспорт
// Параметры:
// Ссылка - ЛюбаяСсылка - объект, значения реквизитов которого необходимо получить.
// - Строка - полное имя предопределенного элемента, значения реквизитов которого необходимо получить.
// Реквизиты - Строка - имена реквизитов, перечисленные через запятую, в формате
// требований к свойствам структуры.
// Например, "Код, Наименование, Родитель".
// - Структура, ФиксированнаяСтруктура - в качестве ключа передается
// псевдоним поля для возвращаемой структуры с результатом, а в качестве
// значения (опционально) фактическое имя поля в таблице.
// Если ключ задан, а значение не определено, то имя поля берется из ключа.
// - Массив, ФиксированныйМассив - имена реквизитов в формате требований
// к свойствам структуры.
// ВыбратьРазрешенные - Булево - если Истина, то запрос к объекту выполняется с учетом прав пользователя, и в случае,
// - если есть ограничение на уровне записей, то все реквизиты вернутся
// со значением Неопределено;
// - если нет прав для работы с таблицей, то возникнет исключение.
// - если Ложь, то возникнет исключение при отсутствии прав на таблицу
// или любой из реквизитов.
//
// Возвращаемое значение:
// Структура - содержит имена (ключи) и значения затребованных реквизитов.
// - если в параметр Реквизиты передана пустая строка, то возвращается пустая структура.
// - если в параметр Ссылка передана пустая ссылка, то возвращается структура,
// соответствующая именам реквизитов со значениями Неопределено.
// - если в параметр Ссылка передана ссылка несуществующего объекта (битая ссылка),
// то все реквизиты вернутся со значением Неопределено.
//
Функция ЗначенияРеквизитовОбъекта(Ссылка, Знач Реквизиты, ВыбратьРазрешенные = Ложь) Экспорт
(49) структура как аргумент - не просто тренд, а стандарт, описанный на ИТС. С телефона не найду ссылку, но там говорится про методы, имеющие большое количество параметров (ориентироваться следует на 5 и более)
Про список областей - то же самое: есть стандарт на ИТС.
ЗначениеРеквизитаОбъекта - исчерпывающую информацию можно получить прямо из описания метода (в том числе примеры вызова). Сигнатура и способы вызова не менялись очень давно, то есть, описанный пример актуален и для древних конфигураций
Про список областей - то же самое: есть стандарт на ИТС.
ЗначениеРеквизитаОбъекта - исчерпывающую информацию можно получить прямо из описания метода (в том числе примеры вызова). Сигнатура и способы вызова не менялись очень давно, то есть, описанный пример актуален и для древних конфигураций
Даже не касаясь темы клипового мышления, все это давно описано в "Системе стандартов и методик разработки конфигураций" на ИТС. Статья рассчитывалась на разработчиков 1С, не знакомых со стандартами разработки в своей области?
Раз Вы не против занудства, позвольте и мне вставить свое. :)
В первом пункте некорректно рассчитывается сумма товаров документа.
Во-первых, Вы используете для обхода выборки цикл, тогда как в результате запроса будет всегда ровно одна строка. На мой взгляд, с которым Вы вполне законно можете не согласиться, для получения данных выборки, где может быть не более одной строки корректнее использовать конструкцию "Если", а не "Цикл". Причина та же, что и для правил именования переменных: так мы подсказываем читающему код разработчику, что в результате не может быть более одной строки. Но это дело вкуса.
Во-вторых, возможны ситуации, когда результатом вычисления суммы товаров документа будет NULL. Это случай с пустой табличной частью "Товары". Мне кажется это также неожиданным для дальнейшего использования результатом, и предпочтительнее здесь получить именно 0. На это намекает инициализация переменой суммы и наличие цикла обхода выборки вместо безусловного "Выборка.Следующий()". Но конечно же, что возвращать - NULL или 0, зависит от решаемой задачи.
В первом пункте некорректно рассчитывается сумма товаров документа.
Во-первых, Вы используете для обхода выборки цикл, тогда как в результате запроса будет всегда ровно одна строка. На мой взгляд, с которым Вы вполне законно можете не согласиться, для получения данных выборки, где может быть не более одной строки корректнее использовать конструкцию "Если", а не "Цикл". Причина та же, что и для правил именования переменных: так мы подсказываем читающему код разработчику, что в результате не может быть более одной строки. Но это дело вкуса.
Во-вторых, возможны ситуации, когда результатом вычисления суммы товаров документа будет NULL. Это случай с пустой табличной частью "Товары". Мне кажется это также неожиданным для дальнейшего использования результатом, и предпочтительнее здесь получить именно 0. На это намекает инициализация переменой суммы и наличие цикла обхода выборки вместо безусловного "Выборка.Следующий()". Но конечно же, что возвращать - NULL или 0, зависит от решаемой задачи.
1) Пример 1, 2,3
Так нельзя
IDE должен сам искать ошибки, в языке ява например придумано много доп. компонентов псевдо SQL язык чтоб ошибки выходили в DesignTime а не RunTime
2) Пример 4
Так нельзя.
С новой строки без отсупа должна находиться новая логическая операция а не продолжение прошлой.
3) Пример 5
Так нельзя.
Слово "Тогда" должно находиться с новой строчки если в условии несколько проверок
4) Пример 6
Так нельзя.
"Мягкий" хардкодинг надо делать путём создания функции в общем модуле
5) Пример 7
Так нельзя.
Международный стандарт правильного именования переменных "Венгерская нотация" говорит что перед именем переменной надо писать тип переменной(сокращённо)
например
ТЗНоменклатура
а не НоменклатураПоступления
6) Пример 8
Так нельзя.
Процедуры и функции должны быть "самодокументируемые" чтоб было всё понятно без документации.
Чему только людей учите :(
Так нельзя
IDE должен сам искать ошибки, в языке ява например придумано много доп. компонентов псевдо SQL язык чтоб ошибки выходили в DesignTime а не RunTime
2) Пример 4
Так нельзя.
С новой строки без отсупа должна находиться новая логическая операция а не продолжение прошлой.
3) Пример 5
Так нельзя.
Слово "Тогда" должно находиться с новой строчки если в условии несколько проверок
4) Пример 6
Так нельзя.
"Мягкий" хардкодинг надо делать путём создания функции в общем модуле
5) Пример 7
Так нельзя.
Международный стандарт правильного именования переменных "Венгерская нотация" говорит что перед именем переменной надо писать тип переменной(сокращённо)
например
ТЗНоменклатура
а не НоменклатураПоступления
6) Пример 8
Так нельзя.
Процедуры и функции должны быть "самодокументируемые" чтоб было всё понятно без документации.
Чему только людей учите :(
(68)пишу на одном скриптовом языке с динамической типизацией, в соглашении к этому языку не встречал рекомендаций использовать ВН. Хотя вот аннотацию типов вводят в стандарты.
В хороших языках программирования со строгой типизацией венгерская нотация не нужна конечно, там тип переменной итак строго задан, но это не про 1С
(69) Поддержу по примеру 4,
Встроенный инструмент форматирования предназначен для оформления управляющих конструкций встроенного языка и не умеет ни в один из пунктов .
Поэтому аппелирование к нему в данном случае считаю некорректным, а отступы конструктора запросов более каноничными.
Форматирование синтаксических конструкций
Текстовый редактор системы 1С:Предприятие предоставляет функции автоматического форматирования управляющих конструкций встроенного языка.
Помимо автоматического форматирования текста модуля в процессе ввода, можно также отформатировать уже введенный текст. Для этого необходимо выделить блок текста, который требуется отформатировать, и выбрать "Текст - Блок - Форматировать". При этом текстовый редактор проанализирует текст модуля и произведет его форматирование, при котором содержимое каждой синтаксической конструкции будет сдвинуто вправо на величину табуляции независимо от первоначального расположения строк (лидирующих пробелов).
(с) сп
Текстовый редактор системы 1С:Предприятие предоставляет функции автоматического форматирования управляющих конструкций встроенного языка.
Помимо автоматического форматирования текста модуля в процессе ввода, можно также отформатировать уже введенный текст. Для этого необходимо выделить блок текста, который требуется отформатировать, и выбрать "Текст - Блок - Форматировать". При этом текстовый редактор проанализирует текст модуля и произведет его форматирование, при котором содержимое каждой синтаксической конструкции будет сдвинуто вправо на величину табуляции независимо от первоначального расположения строк (лидирующих пробелов).
(с) сп
Встроенный инструмент форматирования предназначен для оформления управляющих конструкций встроенного языка и не умеет ни в один из пунктов .
Поэтому аппелирование к нему в данном случае считаю некорректным, а отступы конструктора запросов более каноничными.
(74)
1) Давно Вики стала авторитетным источником учитывая что вносить правки в неё может любой желающий, даже не имеющий опыта работы программистом?
2) В вопросе написания когда под 1С сайт ИТС куда авторитетнее чем Вики.
не надо думать что "сайт ИТС" более авторитетный чем википедия :)
1) Давно Вики стала авторитетным источником учитывая что вносить правки в неё может любой желающий, даже не имеющий опыта работы программистом?
2) В вопросе написания когда под 1С сайт ИТС куда авторитетнее чем Вики.
(73) В своей книге автор писал, что он не заставляет писать так, как он говорит, он лишь приводит свои примеры и примеры других известных программистов, почему так ему кажется удобнее. Я книгу давно читал, но не могу вспомнить, почему не стоит писать тип переменной перед ее параметром? Конкретно меня интересуют такие переменные типа "СтруктураПараметровПолученияПортфелейКонтрагентов" или "ТаблицаЗначенийПредварительнаяНовогоПортфеля". Почему тут плохо использовать Структура и ТаблицаЗначений?
(136)
Указание типа переменной в языке с динамической типизацией может ввести в заблуждение относительно её типа.
Ничего плохого нет в переменной тзПредварительная, плохо когда начинают весь код писать в таком стиле, придумывают целую систему типов, начинают в название переменной добавлять префиксы означающие простые типы и тд.
Почему тут плохо использовать Структура и ТаблицаЗначений?
Указание типа переменной в языке с динамической типизацией может ввести в заблуждение относительно её типа.
Ничего плохого нет в переменной тзПредварительная, плохо когда начинают весь код писать в таком стиле, придумывают целую систему типов, начинают в название переменной добавлять префиксы означающие простые типы и тд.
(60)Мне нравится вот так писать условия (когда их больше 2,3-х)
В общем люблю когда условия выровнены
Аналогично хорошо так же декларировать аргументы функций и вызовы самих функций (когда их больше 3,4, хотя большое число аргументов у функций - тоже считается не очень хорошим тоном - но если они в основном не обязательны и могут быть заданы поименовано при вызове функции - то это даже очень удобно)
Жаль 1С не поддерживает именованные аргументы - как многие из современных языков программирования - типа вот так:
Ну а про отсутствие в 1С кортежей - я вообще молчу :-(
Хотя динамические структуры - вещь очень полезная - предпочитаю их для передачи параметров!
Если ( Условие1=Значение1
И Условие2=Значение2
И Условие3=Значение2
)
ИЛИ Проверка1()
ИЛИ Проверка2()
ИЛИ Проверка3()
Тогда
КонецЕсли;
ПоказатьВ общем люблю когда условия выровнены
Аналогично хорошо так же декларировать аргументы функций и вызовы самих функций (когда их больше 3,4, хотя большое число аргументов у функций - тоже считается не очень хорошим тоном - но если они в основном не обязательны и могут быть заданы поименовано при вызове функции - то это даже очень удобно)
функция МояФункция( Аргумент1,
Аргумент2,
Аргумент3=неопределено,
Аргумент4=1)
возврат "Результат";
КонецФункции
рез = МояФункция( Переменная1,
Переменная2.Поле1,
,
6273);
ПоказатьЖаль 1С не поддерживает именованные аргументы - как многие из современных языков программирования - типа вот так:
рез = МояФункция( Переменная1,
Аргумент3:6273,
Аргумент2:Переменная2.Поле1);
Ну а про отсутствие в 1С кортежей - я вообще молчу :-(
Хотя динамические структуры - вещь очень полезная - предпочитаю их для передачи параметров!
(127)
1) В том то и дело - что ТОГДА я располагаю на том же уровне что и ЕСЛИ - т.к. с моей точки зрения семантически это конструкции одного уровня выражения - слово ЕСЛИ открывает блок условий - слово ТОГДА - открывает блок основного тел условия - как слово ИНАЧЕ - открывает блок второй ветви тела ветвления. По аналогии с оператором
ПОПЫТКА
//Код тела попытки
ИСКЛЮЧЕНИЕ
//Код тела исключения
//Если бы 1С подерживало был бы и 3-й блок
//ЗАВЕРШЕНИЕ
//Код тела завершения алгоритма при любом исходе попытки
КОНЕЦПОПЫТКИ
аналогично и с циклами
ПОКА
//Условия
ЦИКЛ
//Тело цикла
КОНЕЦЦИКЛА
В современных языках такие конструкции всё чаще могут интерпретироваться как выражения и эти ключевые слова разделяют секции выражений. Секция ТОГДА никак не вложена в секцию ЕСЛИ - и поэтому должна быть на одном уровне с ней.
Но это мой мнение.
2) Ну я так и написал - когда их больше 3,4 - читайте больше четырёх
3) Но всё же гораздо удобнее при числе аргументов больше 4 - это использовать уже именованную префиксацию аргументов при их вызове - т.к. когда их очень много (а 5 и более это уже много) в них очень тяжело ориентироваться как при написании вызова функции, так и при анализе текста.
И особенно это удобно когда большая часть таких аргументов не обязательные (со значениями по умолчанию) и используются то одни то другие в разных местах им в разных сочетаниях - особенно когда ещё и целыми группами используются и не используются
Но, обычно я современных языках программирования применение именной адресации не накладывает условий на дизайн самой функции; не накладывает обязательств всегда вызывать функции именно с именованными аргументами; и можно даже комбинировать вызов (как это у меня показано): когда часть аргументов вызываются не именованно - в порядке их декларации в заголовке функции, а часть именовано - в любом порядке и составе.
Но ещё раз замечу - на мой взгляд при большом числе аргументов - их удобнее передавать уже через динамические структуры (а в статических языках для этого рекомендуют создавать статические структурные типы) - тем более, что 1С EDT поддерживает специальные заголовки комментариев для параметров типа "Структура" что даёт всплывающую подсказку по их составу в IDE - жаль нет пока функции рефакторинга по извлечению создания такой структуры из имени исползованной функции.
Кстати, передача параметров через структуру - это очень удобное решение - когда к функции добавляются новые параметры (не обязательные для всех уже используемых месть вызова функции) - что позволяет не переписывать код (и уж тем более когда они удаляются, или переставляются).
Более того данное решение просто обладает невероятной мощью - когда используется сквозная структура передачи параметров сразу в несколько функций глубокой вложенности - особенно это удобно когда нужно расширить параметры глубоко вложенной функции и передать их где-то ещё сверху, в начальной точке вызова, чтобы не переписывать все вложенные функции среднего уровня вложенности. Это очень здорово помогает при интеграции доработок в конфигурации от других вендоров (не важно - используются расширения конфигураций или нет).
1) В том то и дело - что ТОГДА я располагаю на том же уровне что и ЕСЛИ - т.к. с моей точки зрения семантически это конструкции одного уровня выражения - слово ЕСЛИ открывает блок условий - слово ТОГДА - открывает блок основного тел условия - как слово ИНАЧЕ - открывает блок второй ветви тела ветвления. По аналогии с оператором
ПОПЫТКА
//Код тела попытки
ИСКЛЮЧЕНИЕ
//Код тела исключения
//Если бы 1С подерживало был бы и 3-й блок
//ЗАВЕРШЕНИЕ
//Код тела завершения алгоритма при любом исходе попытки
КОНЕЦПОПЫТКИ
аналогично и с циклами
ПОКА
//Условия
ЦИКЛ
//Тело цикла
КОНЕЦЦИКЛА
В современных языках такие конструкции всё чаще могут интерпретироваться как выражения и эти ключевые слова разделяют секции выражений. Секция ТОГДА никак не вложена в секцию ЕСЛИ - и поэтому должна быть на одном уровне с ней.
Но это мой мнение.
2) Ну я так и написал - когда их больше 3,4 - читайте больше четырёх
3) Но всё же гораздо удобнее при числе аргументов больше 4 - это использовать уже именованную префиксацию аргументов при их вызове - т.к. когда их очень много (а 5 и более это уже много) в них очень тяжело ориентироваться как при написании вызова функции, так и при анализе текста.
И особенно это удобно когда большая часть таких аргументов не обязательные (со значениями по умолчанию) и используются то одни то другие в разных местах им в разных сочетаниях - особенно когда ещё и целыми группами используются и не используются
Но, обычно я современных языках программирования применение именной адресации не накладывает условий на дизайн самой функции; не накладывает обязательств всегда вызывать функции именно с именованными аргументами; и можно даже комбинировать вызов (как это у меня показано): когда часть аргументов вызываются не именованно - в порядке их декларации в заголовке функции, а часть именовано - в любом порядке и составе.
Но ещё раз замечу - на мой взгляд при большом числе аргументов - их удобнее передавать уже через динамические структуры (а в статических языках для этого рекомендуют создавать статические структурные типы) - тем более, что 1С EDT поддерживает специальные заголовки комментариев для параметров типа "Структура" что даёт всплывающую подсказку по их составу в IDE - жаль нет пока функции рефакторинга по извлечению создания такой структуры из имени исползованной функции.
Кстати, передача параметров через структуру - это очень удобное решение - когда к функции добавляются новые параметры (не обязательные для всех уже используемых месть вызова функции) - что позволяет не переписывать код (и уж тем более когда они удаляются, или переставляются).
Более того данное решение просто обладает невероятной мощью - когда используется сквозная структура передачи параметров сразу в несколько функций глубокой вложенности - особенно это удобно когда нужно расширить параметры глубоко вложенной функции и передать их где-то ещё сверху, в начальной точке вызова, чтобы не переписывать все вложенные функции среднего уровня вложенности. Это очень здорово помогает при интеграции доработок в конфигурации от других вендоров (не важно - используются расширения конфигураций или нет).
Вот мне интересно, насколько ожидаема ситуация, что люди, для которых "время-деньги" вместо 1 строки с разыменованием объекта будут писать простынку запроса с обходом результата?
(77) в языке java тоже раньше делали такой "ускоряющий" код,
но теперь придумали новый псевдоязык Query DSL
смысл которого только в том что при неправильном написании имени поля(колонки БД) приведёт к ошибке в DesignTime(IDE,конфигуратор) а не в RunTime(у пользователей)
Просто 1С отстаёт лет на 5-10 от нормальных языков программирования.
Надёжность программы намного важнее чем скорость !
но теперь придумали новый псевдоязык Query DSL
смысл которого только в том что при неправильном написании имени поля(колонки БД) приведёт к ошибке в DesignTime(IDE,конфигуратор) а не в RunTime(у пользователей)
Просто 1С отстаёт лет на 5-10 от нормальных языков программирования.
Надёжность программы намного важнее чем скорость !
(83)Да, в 1С очень не хватает псевдодекларативной техники организации выборок из БД (и не только из БД) по аналогии описанной Вами, или LINQ из C#
А вообще - будущее за декларативными языками описания бизнес логики - где написанные команды будут восприниматься как требования и намерения к достижению результата, а интерпретатор ещё на стадии конфигурирования будет их перекладывать на оптимальные внутренние инструкции к runtime-процессору (каким бы он ни был - оптимально сейчас - это LLVM-машина или Java runtime-машина, но можно и сразу в инструкции ЦПУ компилировать - хотя это плохая идея, уж лучше сначала в LLVM-код а уже на стадии выполнения делать JIT-компиляцию), с оптимизацией и распараллеливанием выполнения, при необходимости.
А вообще - будущее за декларативными языками описания бизнес логики - где написанные команды будут восприниматься как требования и намерения к достижению результата, а интерпретатор ещё на стадии конфигурирования будет их перекладывать на оптимальные внутренние инструкции к runtime-процессору (каким бы он ни был - оптимально сейчас - это LLVM-машина или Java runtime-машина, но можно и сразу в инструкции ЦПУ компилировать - хотя это плохая идея, уж лучше сначала в LLVM-код а уже на стадии выполнения делать JIT-компиляцию), с оптимизацией и распараллеливанием выполнения, при необходимости.
(83) Поддерживаю!
Код мы читаем раз в сто больше, чем пишем. Порой приходится для одной строки прочитать целый фолиант. А это все ВРЕМЯ, а значит ДЕНЬГИ. А зачем все это надо можно почитать вбив в Гугле "чистый код". Наверное не зря признанные метры программирования столько пишут об этом. Огорчает, что низкий порог вхождения в профессию программист 1С тянет за собой тонны кода, с которым потом бизнесу приходится жить и оплачивать потраченное программистами время.
Код мы читаем раз в сто больше, чем пишем. Порой приходится для одной строки прочитать целый фолиант. А это все ВРЕМЯ, а значит ДЕНЬГИ. А зачем все это надо можно почитать вбив в Гугле "чистый код". Наверное не зря признанные метры программирования столько пишут об этом. Огорчает, что низкий порог вхождения в профессию программист 1С тянет за собой тонны кода, с которым потом бизнесу приходится жить и оплачивать потраченное программистами время.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|