Стандарт фирмы 1С «Структура модуля» содержит в себе рекомендации о перечене и составе элементов разделов на которые предлагается разделить программный модуль. Само требование о разделении кода модуля на разделы призвано повысить читаемость кода и упростить внесение изменений в код разными авторами (разработчиками) как при коллективной разработке, так и при доработке прикладных решений на конкретных внедрениях. За туманными выражениями «повысить читаемость» и «упростить внесение изменений» теряется настоящая цель — снижение сложности системы.
В этой небольшой статье я попытаюсь продемонстрировать более удачное применение областей модуля. Как мне представляется, на самом деле, требуется не повысить читаемость кода, а структурировать его, улучшить его понимаемость, и облегчить внесение изменений.
На мой взгляд, даже названия разделов неудачны, например:
— «ПрограммныйИнтерфейс» — интересно, а какой еще как не «Программный» он может быть в данном случае,
— «СлужебныеПроцедурыИФункции» — слишком длинно, к тому же в эту область можно включить вообще любую процедуру и функцию. Критерии считать функциональную единицу «служебной» или «не служебной», как правило, размыты.
— «ОбработчикиСобытийТаблицыФормы» — уснешь, пока дочитаешь до конца, проще и компактнее просто «События».
Предложенный подход не использует в полной мере возможности областей кода. Ведь можно создавать вложенные области. Более того, вложенные области могут иметь одинаковые имена, т.е. например мы можем создать область
#Область Таблицы
#Область Запасы
#Область Команды
#КонецОбласти
#КонецОбласти
#Область Услуги
#Область Команды
#КонецОбласти
#КонецОбласти
#КонецОбласти
Вот какие разделы рекомендуется использовать.
Для модуля формы:
#Область Форма
#КонецОбласти
#Область Элементы
#КонецОбласти
#Область Таблицы
#Область <ИмяТаблицы>
#Область Команды
#КонецОбласти
#КонецОбласти
#КонецОбласти
#Область Команды
#КонецОбласти
#Область Оповещения
#КонецОбласти
#Область Подключаемые
#КонецОбласти
#Область Методы
#Область НаКлиенте
#КонецОбласти
#Область НаСервере
#КонецОбласти
#КонецОбласти
В разделе «Форма» собираются все обработчики событий формы.
В разделе «Элементы» собираются все обработчики событий элементов формы (кроме таблиц и табличных полей).
В разделе «Таблицы» собираются обработчики событий всех таблиц формы. При необходимости в область таблицы можно добавить вложенную область «Команды» и включить в нее все команды относящиеся к таблице.
В разделе «Оповещения» собираются все оповещения о событиях формы.
В разделе «Подключаемые» указываются все подключаемые процедуры и функции формы.
В разделе «Методы» собираются все остальные процедуры и функции. В исходном варианте он содержит вложенные области по директивам компиляции, соответственно «НаКлиенте», «НаСервере». Вначале были еще и области «НаСервереБезКонтекста», «НаКлиентеНаСервереБезКонтекста», но согласно стандарта «Правила создания общих модулей» не рекомендуется определять модули одновременно для клиента и для сервера. Здесь принцип такой же. По сути в модуле формы, с помощью областей определяются клиентская и серверная часть формы. Общий модуль, да может быть смешанным, но в этом случае, это скорее получается некий пакет связанного функционала, который должен уметь работать и на клиенте и на сервере.
Исходный замысел был в том чтобы разделить логику модуля на клиентскую и серверную части соответственно, однако, естественно, при увеличении объема кода, принятый набор областей перестанет справляться со сложностью. В этом случае, я переразбиваю функции, добавляя область «Пакеты», и уже в ней указываю вложенные области, группируя функции. Например:
#Область Пакеты
#КонецОбласти
Хотя появление этой области, скорее говорит о том что функционал формы перегружен. Впрочем, для каких-то сложных обработок, это может быть применимо.
Для модуля объекта:
#Область Интерфейс
#КонецОбласти
#Область События
#КонецОбласти
#Область Методы
#КонецОбласти
Для общего модуля (и для модуля менеджера):
#Область Интерфейс
#КонецОбласти
#Область Методы
#КонецОбласти
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Если вы укоротили имена областей, это еще не значит, что повысили читаемость кода.
Вот смотрите, например, область «ОбработчикиСобытийФормы«. Любому разработчику понятно, ЧТО в этой области должно храниться. Вы же предлагаете назвать эту область расплывчато «Форма«. Да это название короче, но поставьте себя на место разработчика, который не знаком с вашим стандартом. Сможет ли он без ваших объяснений догадаться, что писать в эту область? Вы уверены, что он впишет туда только обработчики событий формы? То же самое и с другими областями (Элементы, Таблицы, Интерфейс и т.д.).
По поводу дополнительных областей, которых нет в стандарте, тоже не согласен. Все дополнительные области следует помещать в «СлужебныеПроцедурыИФункции«. Именно поэтому у нее такое общее и расплывчатое название. Внутри нее можно поместить области «Подключаемые«, «Оповещения» и др.
Вообще, гораздо проще освоить общий стандарт, чем придумывать свой. Ведь если придешь в новую команду и начнешь всем объяснять, что вы пишете неправильно, а я правильно, то встретишь непонимание и недоумение со стороны коллег.
Лично я давно уже привык к стандартным областям, и могу с уверенностью заявить, что в них лаконично укладывается 99.9% всех решаемых задач, и был бы сильно против, если бы мне кто-нибудь начал навязывать подобные улучшения.
(1) Спасибо, Юрий! Я благодарен вам за высказывание своего мнения. Никоим образом ничего никому не навязываю, а просто излагаю свое мнение, свой опыт. В моем сообщении предлагается не только сократить имена областей, но и использовать вложенные области. «ОбработчикиСобытийФормы» все-таки считаю слишком длинным наименованием, хотя, безусловно, оно более точное.
🙂 исходя из каких предпосылок вы пришли к умозаключению что я собираюсь
:-)? Пусть это останется загадкой…
Даже в самой 1С точность «стандарта» соблюдается, скажем так, «с доработками». Достаточно посмотреть на исходные коды конфигураций УП, УНФ и Документооборот. Разные команды даже внутри самой 1С изменяют его под себя.
(2) открыл Документооборот 2.0.14.4. Увидел там, что стандартные области соблюдаются. Просмотрел несколько форм, модулей менеджеров, модулей объектов. В чем именно вы заметили несоблюдение? Приведите конкретный пример.
Других конфигураций под рукой нет.
Про вложенные области я не упомянул, т.к. они не регламентированы. Во вложенных областях каждый может писать, что считает правильным.
Скажу вам по своему опыту, что очень трудно приучить разработчиков соблюдать даже типовой стандарт. А уж тем более предлагать кому-нибудь свой стандарт — дело совсем неблагодарное. Но желаю вам удачи в этом начинании)
слова «Форма» и «Элементы» — это служебные слова, их нельзя использовать в качестве именований переменных.
Про точность стандарта в самой 1С — единственное место, где все всегда «по стандарту» — это разве что последняя редакция БСП. Конфигурации 1С не стоят на месте (и никогда не стояли), как и сам стандарт. Слишком много старого кода, чтобы с ним бороться, поэтому еще очень долго будем наблюдать отрыв в конфигурация 1С от своего же стиля. Особенно в БП УТ.
Элементарный пример. Даже не буду писать сам, а процитирую ИТС (
6.1. Имена функций в общем случае следует образовывать от описания возвращаемого значения.
Неправильно:
Функция ПолучитьПолноеИмяПользователя()
Функция СоздатьПараметрыЗаполненияЦенПоставщика()
Функция ОпределитьДатуНачалаСеанса()
Правильно:
Функция ПолноеИмяПользователя()
Функция НовыеПараметрыЗаполненияЦенПоставщика()
Функция ДатаНачалаСеанса()
Этого когда-то там не было. А родилось такое правило (как и многие другие) из-за существующих прецедентов избыточности кода. Или комментарии взять — когда-то по стилистике требовалось писать комменты везде, сейчас — только там, где это действительно необходимо. Не буду уже перепечатывать ИТС, кинусь ссылкой — .
Не в обиду, но данная статья — велосипед, с квадратными колесами. Желаю автору не тратить время на эти изыскания, а изучать стандарты вендора. Чтобы ваять что-то значимое на 1С — необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми. Чем больше 1С-негов это осознает, тем проще всем нам будет жить.
Все эти попытки группировок модулей с помощью областей — от Лукавого. Как и автор статьи, одно время пытался навести порядок в своих алгоритмах с помощью областей. Придумывал имена, менял порядок следования, ломал голову куда-что перебросить с риском развалить всю хатку. И что? Я стал быстрее программировать? Нахожу быстрее требуемые процедуры-функции? Быстрее переключаюсь? Логика понятней? Не знаю как у вас, Господа, но мне эти группировки никак жизнь не облегчают. Всегда пляшу от формы. И все наши с вами попытки навести красоту и сделать нашу программистскую жизнь легче, — потеря времени, пока сама фирма 1С не обратит свои взоры в эту сторону. Как по мне, боковая навигационная панель к программному модулю, в которой перечислялись бы применительно к текущему модулю все вызывающие и вызываемые модули была бы куда интересней. На ней же события-команды не помешали бы. Ну, может быть, еще чего, — можно пофантазировать. Мне не нужна структура всея конфигурации… мне нужна подсказка по структуре здесь и сейчас, в текущем модуле. А автору за попытку улучшения стиля таки спасибо. Думал… мечтал… фантазировал… решал… предлагал… Ну что с того, что пошел против общего течения? Зато дал повод и нам помечтать. 🙂
(5)Раззадорился я малость.. 🙂 Ну сами подумайте! С какой стати мы сами должны группировать? Что, при создании нового события не ясно, что это событие и нужно его включить в область событий в модуле формы для конкретного реквизита формы? Нееет, бросим это событие в конец модуля формы, — так думает фирма 1С. Полагает, что нам доставляет удовольствие после создания нового события, выщемить его, найти в модуле формы область событий для реквизита формы и туда его перекинуть, — чтобы красиво было и всем все понятно! 🙂
Я не в претензии к фирме 1С. Я снимаю перед разработчиками 1С-Предприятие шляпу за труд, который еще никому не удавался. Но… некоторые моменты вызывают улыбку. То же создание стандарта, указанное автором статьи. Не читал, но по контексту уже догадался о чем. Вместо того, чтобы при создании новых событий реквизитов формы бросать их в соответствующие области модуля (ведь понятно какие, можно создать на автомате), опубликуем стандарт! Пусть программисты 1С отдохнут на легком труде… 🙂
(5)
Вот как минимум процитированное должно соблюдаться, при правильном использовании областей. Так-как точно не надо «шерстить» весь модуль для поиска нужной функции, достаточно развернуть нужную область.
С быстрым переключением та же история — развернул область, нашёл нужную функцию.
С логикой чуть сложнее, больше зависит от образа мышления того разработчика чей код смотришь.
И ещё, стоит учесть, что имена областей в стандарте полностью соответствуют устоявшимся именам областей модулей. Просто раньше приходилось их выделять при помощи комментариев, а сейчас появился более удобный инструмент.
(7) «На безрыбье — и рак рыба!» И есть очевидная польза от областей многим из нас. Равно, как некоторым из нас это лишь дополнительная головная боль при наведении порядка, который в массе можно было бы поддерживать автоматически. Да, области нужны для выделения крупномасштабной структуры… А в плане поиска требуемого… еще ни разу они не ускорили мне работу. Замедлили — да! — в попытке вспомнить что и в какой области. в каком месте находится… Играл я как-то с «свернуть-развернуть» область пытаясь найти что-то, — удовольствия не получил. 🙂 Наверное, от привычек многое зависит, отработанных подходов. Каждый выбирает, что ему удобней.
(8)
Можно. И разработчики платформы ведут работы в этом направление. Но, у них есть масса более важных и приоритетных задач, ради ускоренной реализации которых лично я готов мирится с «неинтеллектуальной» вставкой процедур обработчиков в модули…
П.С.: Было уже схожее обсуждение на партнёрском форуме. Лично я тогда голосовал за «отложить» на потом работы по «юзабилити конфигуратора». И сейчас моё мнение не изменилось.
Поставил плюс, так как затронута важная тема.
В целом со статьей не согласен — нужно следовать стандартам уже имеющимся.
Так много комментариев, спасибо всем коллегам. Начну с тех сообщений, которые были добавлены позже.
(10) Безусловно, профессиональный подход к командной разработке любого сложного продукта требует чтобы все участники следовали уже имеющимся стандартам. Но разве это утверждение запрещает рассматривать предложения по улучшению действующего стандарта?
(7)
Не совсем конечно полностью, кое-что дорабатывали.
(6) Ну по поводу удобства использования Конфигуратора было написано уже довольно много. Скажем так, в этом плане Конфигуратору есть куда расти. Лично я очень большие надежды возлагаю на новую среду разработки на базе Eclipse.
(5) Ну, как говорится, «доброе слово и кошке приятно» 🙂 Области кода используются во многих средах разработки, та же VS Microsoft например. Лично я нахожу их очень удобными и полезными, но тут, конечно, это вопрос личных предпочтений.
Я не иду против течения, скорее я пытаюсь сделать движение по течению более комфортным и эффективным. 🙂
(4)
Но имена областей кода не являются переменными.
🙂 там тоже есть ошибки и недочеты, как и в любом творении рук человеческих.
Данная статья, это изложение моего «оценочного суждения» основанного на опыте. Эту информацию я опубликовал для того чтобы поделиться с сообществом, на мой взгляд, полезной идеей. Возможно, кому-то она понравится и кто-то из коллег воспользуется ей.
🙂 «Что позволено Юпитеру, то не позволено быку». Я делаю второе, но никогда не буду делать первого 🙂
С этим не поспоришь. Но, увы, практика показывает что императив «жестко соблюдаются всеми» является таки мечтой. В реальности обычно «более или менее соблюдаются всеми».
А кто такие 1С-неги?
Про имена областей — , п.1.3
Вообще любые именования методов, областей должны удовлетворять . Несмотря на «удобное» подчеркивание в области. Смысл которого мне не ясен в свете этих правил.
«практика показывает что императив «жестко соблюдаются всеми» является таки мечтой» — как-раз из-за того что все хотят «хорошо», но каждый по-своему. Я тоже сперва велся на подчеркивание в областях, пробовал как-то под себя это все подогнать. А потом подумал что в 1С наверное не дураки сидят, не просто так это все. И начал оформляться так, как это сказано на ИТС. Сейчас не представляю зачем изобретать что-то иное — видимо привык. Имхо — разработка стандартов не то, чем надо заниматься на работе. Хотя бы потому что все уже придумано, и это реально удобно)) Только к этому надо придти.
(16)
Ваше высказывание, кстати, нарушает 6-ой 1С 🙂
(16)
Исключительно в нерабочее время
«и под хорошую закуску».«Ваше высказывание, кстати, нарушает 6-ой стандарт 1С 🙂 »
— Мы теперь всю прессу стандартом считать будем?) Или только прессу от 1С? Это еще одна ваша идея?
з.ы. Ничего не имею против «изучать чужой опыт, но думать своей головой». Только я не вижу смысла воровать колизей)) Есть правила, вполне удобная база которой надо следовать. А не заниматься фигней, вводя в заблуждение неопытную публику. За публикацию — минус.
(18) Роман, спасибо за высказанное суждение.
Лично меня эти деления на области просто бесят. Вот такое исключительно субъективное мнение…
Страсти отшумели, я поздно увидел публикацию. Мне приятно видеть, что автор
1) озабочен качеством кода,
2) при этом не следует слепо чужим правилам. Хочешь сделать жизнь краше-делай!
По моему опыту, и как видно из обсуждения, мотивация некоторых программистов на вопрос «а зачем украшать код (т.е. страдать ерундой)» строится на постулатах:
* «быстрее я писать не стану. А мне и так удобно». » Всегда пляшу от формы» — как написано выше. (5) Короче, жалко времени.
* «Я же это для себя писал». Второй вариант: под индивидуального заказчика, третий вариант: для нормального решения, но для меня это была разовая работа. Вот так происходит трансформация мышления. А в жизни так: если ты в лесу поворот не показываешь, то и везде так-же ездишь.
Только собственник конечного продукта понимает ценность красивого и понятного кода. Это и надежность, и реальные трудозатраты в сопровождении, которые могут превышать первоначальный труд на создание.
А что касается отношения к строгости стандартов, то должна быть некоторая незашоренность. Нравятся тебе более короткие названия — реши и пиши так.
По поводу областей спорят: нужны — не нужны. Обалденно нужны! Но правило должно не быть: «а этот блок обязательно в область». У меня так: размер модуля до 2-3 экранов — можно не разбивать по областям. Больше — обязательно.
Автору — плюс.
(21)Здесь немного упомянули мое имя всуе… 🙂 Хочу дать некоторое дополнительное уточнение (назову так) к свои комментариям. Я, вообще-то, не против областей как это может показаться, и стандартов по их использованию. Напротив, я зА использование областей. И если бы участвовал в разработке типовых решений, непременно следовал бы им для поддержания единообразия в программировании и еще потому, что иначе решение не было бы принято как типовое. Но… я против дурной работы в тех случаях, когда я являюсь единственным постановщиком и исполнителем всех работ, связанных с программированием. В условиях, когда платформа в нынешнем состоянии никак не поддерживает программистов в эффективном использовании этих самых областей. А в большинстве своем эти области могут поддерживаться платформой на автомате (что скорее всего будет реализовано в будущем). А что получается? Я навел порядок в программном коде, разложил все по областям, а потом (спустя длительное время, когда все уже давно забыто) добавил еще пару-тройку событий и… «наша песня хороша — начинай сначала» с наведения порядка, тупого перетаскивания событий по областям. Мы что, обезьяны, чтобы тупо перекладывать все с места на место? Ничего более умного нельзя реализовать? Понятное дело, разработчикам пока что не до таких мелочей. А нам остается ждать. И тогда уж, мы будем поддерживать области собственными усилиями только там, где платформа в принципе не способна разделить процедуры-функции по областям, ибо все «правила» в голове программиста.
(21) Спасибо, Игорь. Divide et impera — разделяй и властвуй. Но как разделить правильно? Как разделить лучше? Статья — размышление на тему как точнее разделять код на ясные блоки, с помощью имеющегося в наличии инструмента — областей кода. Мнения коллег разнятся, конечно, все люди разные. 🙂