Улучшение стандарта "Структура модуля"

02.06.17

Описывается структура областей модулей, которую я использую при разработке на своих проектах. Обсуждаются недостатки стандарта 1С "Структура модуля". Предложен улучшенный подход к работе со структурой модуля.

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

В этой небольшой статье я попытаюсь продемонстрировать более удачное применение областей модуля. Как мне представляется, на самом деле, требуется не повысить читаемость кода, а структурировать его, улучшить его понимаемость, и облегчить внесение изменений.

На мой взгляд, даже названия разделов неудачны, например:
- "ПрограммныйИнтерфейс" - интересно, а какой еще как не "Программный" он может быть в данном случае,
- "СлужебныеПроцедурыИФункции" - слишком длинно, к тому же в эту область можно включить вообще любую процедуру и функцию. Критерии считать функциональную единицу "служебной" или "не служебной", как правило, размыты.
- "ОбработчикиСобытийТаблицыФормы" - уснешь, пока дочитаешь до конца, проще и компактнее просто "События".

Предложенный подход не использует в полной мере возможности областей кода. Ведь можно создавать вложенные области. Более того, вложенные области могут иметь одинаковые имена, т.е. например мы можем создать область

#Область Таблицы
       #Область Запасы
               #Область Команды
               #КонецОбласти
        #КонецОбласти
        #Область Услуги
               #Область Команды
               #КонецОбласти
        #КонецОбласти
#КонецОбласти

Вот какие разделы рекомендуется использовать.

Для модуля формы:

#Область Форма
#КонецОбласти

#Область Элементы
#КонецОбласти

#Область Таблицы
        #Область <ИмяТаблицы>
                #Область Команды
                #КонецОбласти
        #КонецОбласти
#КонецОбласти

#Область Команды
#КонецОбласти

#Область Оповещения
#КонецОбласти

#Область Подключаемые
#КонецОбласти

#Область Методы
        #Область НаКлиенте
        #КонецОбласти

        #Область НаСервере
        #КонецОбласти
#КонецОбласти

В разделе "Форма" собираются все обработчики событий формы.
В разделе "Элементы" собираются все обработчики событий элементов формы (кроме таблиц и табличных полей).
В разделе "Таблицы" собираются обработчики событий всех таблиц формы. При необходимости в область таблицы можно добавить вложенную область "Команды" и включить в нее все команды относящиеся к таблице.
В разделе "Оповещения" собираются все оповещения о событиях формы.
В разделе "Подключаемые" указываются все подключаемые процедуры и функции формы.

В разделе "Методы" собираются все остальные процедуры и функции. В исходном варианте он содержит вложенные области по директивам компиляции, соответственно "НаКлиенте", "НаСервере". Вначале были еще и области "НаСервереБезКонтекста", "НаКлиентеНаСервереБезКонтекста", но согласно стандарта "Правила создания общих модулей" не рекомендуется определять модули одновременно для клиента и для сервера. Здесь принцип такой же. По сути в модуле формы, с помощью областей определяются клиентская и серверная часть формы. Общий модуль, да может быть смешанным, но в этом случае, это скорее получается некий пакет связанного функционала, который должен уметь работать и на клиенте и на сервере.

Исходный замысел был в том чтобы разделить логику модуля на клиентскую и серверную части соответственно, однако, естественно, при увеличении объема кода, принятый набор областей перестанет справляться со сложностью. В этом случае, я переразбиваю функции, добавляя область "Пакеты", и уже в ней указываю вложенные области, группируя функции. Например:

#Область Пакеты
#КонецОбласти

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

Для модуля объекта:

#Область Интерфейс
#КонецОбласти

#Область События
#КонецОбласти

#Область Методы
#КонецОбласти

Для общего модуля (и для модуля менеджера):

#Область Интерфейс
#КонецОбласти

#Область Методы
#КонецОбласти

структура модуля стандарты

+9 –2

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Программист Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024 3165 stopa85 12

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023 7556 user1959478 51

Математический тренажер через телеграмм (feat 1С)

Математика и алгоритмы Разное Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.

2 стартмани

29.09.2023 3111 maksa2005 8

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Программист Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023 10905 7 SpaceOfMyHead 18

Мини-обзор разных решений задач

Математика и алгоритмы Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

03.04.2023 4361 RustIG 9

Тестирование средств 1С для решения СЛАУ

Механизмы платформы 1С Математика и алгоритмы Программист Платформа 1С v8.3 Россия Бесплатно (free)

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

23.11.2022 3531 gzharkoj 14

Модель распределения суммы по базе

Математика и алгоритмы Программист Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022 9042 7 kalyaka 11

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Программист Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021 5663 fishca 12

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. json 3349 27.03.17 00:12 Сейчас в теме

Если вы укоротили имена областей, это еще не значит, что повысили читаемость кода.
Вот смотрите, например, область "ОбработчикиСобытийФормы". Любому разработчику понятно, ЧТО в этой области должно храниться. Вы же предлагаете назвать эту область расплывчато "Форма". Да это название короче, но поставьте себя на место разработчика, который не знаком с вашим стандартом. Сможет ли он без ваших объяснений догадаться, что писать в эту область? Вы уверены, что он впишет туда только обработчики событий формы? То же самое и с другими областями (Элементы, Таблицы, Интерфейс и т.д.).
По поводу дополнительных областей, которых нет в стандарте, тоже не согласен. Все дополнительные области следует помещать в "СлужебныеПроцедурыИФункции". Именно поэтому у нее такое общее и расплывчатое название. Внутри нее можно поместить области "Подключаемые", "Оповещения" и др.
Вообще, гораздо проще освоить общий стандарт, чем придумывать свой. Ведь если придешь в новую команду и начнешь всем объяснять, что вы пишете неправильно, а я правильно, то встретишь непонимание и недоумение со стороны коллег.
Лично я давно уже привык к стандартным областям, и могу с уверенностью заявить, что в них лаконично укладывается 99.9% всех решаемых задач, и был бы сильно против, если бы мне кто-нибудь начал навязывать подобные улучшения.

Ответить

2. o.nikolaev 216 27.03.17 00:34 Сейчас в теме

(1) Спасибо, Юрий! Я благодарен вам за высказывание своего мнения. Никоим образом ничего никому не навязываю, а просто излагаю свое мнение, свой опыт. В моем сообщении предлагается не только сократить имена областей, но и использовать вложенные области. "ОбработчикиСобытийФормы" все-таки считаю слишком длинным наименованием, хотя, безусловно, оно более точное.

:-) исходя из каких предпосылок вы пришли к умозаключению что я собираюсь

всем объяснять, что вы пишете неправильно, а я правильно

:-)? Пусть это останется загадкой...

Даже в самой 1С точность "стандарта" соблюдается, скажем так, "с доработками". Достаточно посмотреть на исходные коды конфигураций УП, УНФ и Документооборот. Разные команды даже внутри самой 1С изменяют его под себя.

3. json 3349 27.03.17 00:52 Сейчас в теме

(2) открыл Документооборот 2.0.14.4. Увидел там, что стандартные области соблюдаются. Просмотрел несколько форм, модулей менеджеров, модулей объектов. В чем именно вы заметили несоблюдение? Приведите конкретный пример.
Других конфигураций под рукой нет.

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

Скажу вам по своему опыту, что очень трудно приучить разработчиков соблюдать даже типовой стандарт. А уж тем более предлагать кому-нибудь свой стандарт - дело совсем неблагодарное. Но желаю вам удачи в этом начинании)

4. unichkin 1579 27.03.17 03:29 Сейчас в теме

слова "Форма" и "Элементы" - это служебные слова, их нельзя использовать в качестве именований переменных.
Про точность стандарта в самой 1С - единственное место, где все всегда "по стандарту" - это разве что последняя редакция БСП. Конфигурации 1С не стоят на месте (и никогда не стояли), как и сам стандарт. Слишком много старого кода, чтобы с ним бороться, поэтому еще очень долго будем наблюдать отрыв в конфигурация 1С от своего же стиля. Особенно в БП \ УТ.
Элементарный пример. Даже не буду писать сам, а процитирую ИТС (https://its.1c.ru/db/v8std#content:2149184296:hdoc):
6.1. Имена функций в общем случае следует образовывать от описания возвращаемого значения.

Неправильно:

Функция ПолучитьПолноеИмяПользователя()
Функция СоздатьПараметрыЗаполненияЦенПоставщика()
Функция ОпределитьДатуНачалаСеанса()

Правильно:

Функция ПолноеИмяПользователя()
Функция НовыеПараметрыЗаполненияЦенПоставщика()
Функция ДатаНачалаСеанса()

Этого когда-то там не было. А родилось такое правило (как и многие другие) из-за существующих прецедентов избыточности кода. Или комментарии взять - когда-то по стилистике требовалось писать комменты везде, сейчас - только там, где это действительно необходимо. Не буду уже перепечатывать ИТС, кинусь ссылкой - https://its.1c.ru/db/v8std#content:2149184102:hdoc.

Не в обиду, но данная статья - велосипед, с квадратными колесами. Желаю автору не тратить время на эти изыскания, а изучать стандарты вендора. Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми. Чем больше 1С-негов это осознает, тем проще всем нам будет жить.

Ответить

15. o.nikolaev 216 28.03.17 00:25 Сейчас в теме

(4)

слова "Форма" и "Элементы" - это служебные слова, их нельзя использовать в качестве именований переменных.

Но имена областей кода не являются переменными.

единственное место, где все всегда "по стандарту" - это разве что последняя редакция БСП

:-) там тоже есть ошибки и недочеты, как и в любом творении рук человеческих.

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

не тратить время на эти изыскания, а изучать стандарты вендора

:-) "Что позволено Юпитеру, то не позволено быку". Я делаю второе, но никогда не буду делать первого :-)

Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми

С этим не поспоришь. Но, увы, практика показывает что императив "жестко соблюдаются всеми" является таки мечтой. В реальности обычно "более или менее соблюдаются всеми".

А кто такие 1С-неги?

5. romasna 325 27.03.17 10:38 Сейчас в теме

Все эти попытки группировок модулей с помощью областей - от Лукавого. Как и автор статьи, одно время пытался навести порядок в своих алгоритмах с помощью областей. Придумывал имена, менял порядок следования, ломал голову куда-что перебросить с риском развалить всю хатку. И что? Я стал быстрее программировать? Нахожу быстрее требуемые процедуры-функции? Быстрее переключаюсь? Логика понятней? Не знаю как у вас, Господа, но мне эти группировки никак жизнь не облегчают. Всегда пляшу от формы. И все наши с вами попытки навести красоту и сделать нашу программистскую жизнь легче, - потеря времени, пока сама фирма 1С не обратит свои взоры в эту сторону. Как по мне, боковая навигационная панель к программному модулю, в которой перечислялись бы применительно к текущему модулю все вызывающие и вызываемые модули была бы куда интересней. На ней же события-команды не помешали бы. Ну, может быть, еще чего, - можно пофантазировать. Мне не нужна структура всея конфигурации... мне нужна подсказка по структуре здесь и сейчас, в текущем модуле. А автору за попытку улучшения стиля таки спасибо. Думал... мечтал... фантазировал... решал... предлагал... Ну что с того, что пошел против общего течения? Зато дал повод и нам помечтать. :)

Ответить

6. romasna 325 27.03.17 11:11 Сейчас в теме

(5)Раззадорился я малость.. :) Ну сами подумайте! С какой стати мы сами должны группировать? Что, при создании нового события не ясно, что это событие и нужно его включить в область событий в модуле формы для конкретного реквизита формы? Нееет, бросим это событие в конец модуля формы, - так думает фирма 1С. Полагает, что нам доставляет удовольствие после создания нового события, выщемить его, найти в модуле формы область событий для реквизита формы и туда его перекинуть, - чтобы красиво было и всем все понятно! :)
Я не в претензии к фирме 1С. Я снимаю перед разработчиками 1С-Предприятие шляпу за труд, который еще никому не удавался. Но... некоторые моменты вызывают улыбку. То же создание стандарта, указанное автором статьи. Не читал, но по контексту уже догадался о чем. Вместо того, чтобы при создании новых событий реквизитов формы бросать их в соответствующие области модуля (ведь понятно какие, можно создать на автомате), опубликуем стандарт! Пусть программисты 1С отдохнут на легком труде... :)

13. o.nikolaev 216 28.03.17 00:06 Сейчас в теме

(6) Ну по поводу удобства использования Конфигуратора было написано уже довольно много. Скажем так, в этом плане Конфигуратору есть куда расти. Лично я очень большие надежды возлагаю на новую среду разработки на базе Eclipse.

7. h00k 51 27.03.17 11:22 Сейчас в теме

(5)

Нахожу быстрее требуемые процедуры-функции? Быстрее переключаюсь? Логика понятней?

Вот как минимум процитированное должно соблюдаться, при правильном использовании областей. Так-как точно не надо "шерстить" весь модуль для поиска нужной функции, достаточно развернуть нужную область.
С быстрым переключением та же история - развернул область, нашёл нужную функцию.
С логикой чуть сложнее, больше зависит от образа мышления того разработчика чей код смотришь.

И ещё, стоит учесть, что имена областей в стандарте полностью соответствуют устоявшимся именам областей модулей. Просто раньше приходилось их выделять при помощи комментариев, а сейчас появился более удобный инструмент.

8. romasna 325 27.03.17 11:39 Сейчас в теме

(7) "На безрыбье - и рак рыба!" И есть очевидная польза от областей многим из нас. Равно, как некоторым из нас это лишь дополнительная головная боль при наведении порядка, который в массе можно было бы поддерживать автоматически. Да, области нужны для выделения крупномасштабной структуры... А в плане поиска требуемого... еще ни разу они не ускорили мне работу. Замедлили - да! - в попытке вспомнить что и в какой области. в каком месте находится... Играл я как-то с "свернуть-развернуть" область пытаясь найти что-то, - удовольствия не получил. :) Наверное, от привычек многое зависит, отработанных подходов. Каждый выбирает, что ему удобней.

9. h00k 51 27.03.17 13:29 Сейчас в теме

(8)

можно было бы поддерживать автоматически

Можно. И разработчики платформы ведут работы в этом направление. Но, у них есть масса более важных и приоритетных задач, ради ускоренной реализации которых лично я готов мирится с "неинтеллектуальной" вставкой процедур обработчиков в модули...

П.С.: Было уже схожее обсуждение на партнёрском форуме. Лично я тогда голосовал за "отложить" на потом работы по "юзабилити конфигуратора". И сейчас моё мнение не изменилось.

12. o.nikolaev 216 28.03.17 00:04 Сейчас в теме

(7)

имена областей в стандарте полностью соответствуют устоявшимся именам областей модулей

Не совсем конечно полностью, кое-что дорабатывали.

14. o.nikolaev 216 28.03.17 00:14 Сейчас в теме

(5) Ну, как говорится, "доброе слово и кошке приятно" :-) Области кода используются во многих средах разработки, та же VS Microsoft например. Лично я нахожу их очень удобными и полезными, но тут, конечно, это вопрос личных предпочтений.

Я не иду против течения, скорее я пытаюсь сделать движение по течению более комфортным и эффективным. :-)

21. Dnki 4 19.04.17 10:31 Сейчас в теме

Страсти отшумели, я поздно увидел публикацию. Мне приятно видеть, что автор
1) озабочен качеством кода,
2) при этом не следует слепо чужим правилам. Хочешь сделать жизнь краше-делай!

По моему опыту, и как видно из обсуждения, мотивация некоторых программистов на вопрос "а зачем украшать код (т.е. страдать ерундой)" строится на постулатах:
* "быстрее я писать не стану. А мне и так удобно". " Всегда пляшу от формы" - как написано выше. (5) Короче, жалко времени.
* "Я же это для себя писал". Второй вариант: под индивидуального заказчика, третий вариант: для нормального решения, но для меня это была разовая работа. Вот так происходит трансформация мышления. А в жизни так: если ты в лесу поворот не показываешь, то и везде так-же ездишь.

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

А что касается отношения к строгости стандартов, то должна быть некоторая незашоренность. Нравятся тебе более короткие названия - реши и пиши так.
По поводу областей спорят: нужны - не нужны. Обалденно нужны! Но правило должно не быть: "а этот блок обязательно в область". У меня так: размер модуля до 2-3 экранов - можно не разбивать по областям. Больше - обязательно.
Автору - плюс.

22. romasna 325 19.04.17 11:13 Сейчас в теме

(21)Здесь немного упомянули мое имя всуе... :) Хочу дать некоторое дополнительное уточнение (назову так) к свои комментариям. Я, вообще-то, не против областей как это может показаться, и стандартов по их использованию. Напротив, я зА использование областей. И если бы участвовал в разработке типовых решений, непременно следовал бы им для поддержания единообразия в программировании и еще потому, что иначе решение не было бы принято как типовое. Но... я против дурной работы в тех случаях, когда я являюсь единственным постановщиком и исполнителем всех работ, связанных с программированием. В условиях, когда платформа в нынешнем состоянии никак не поддерживает программистов в эффективном использовании этих самых областей. А в большинстве своем эти области могут поддерживаться платформой на автомате (что скорее всего будет реализовано в будущем). А что получается? Я навел порядок в программном коде, разложил все по областям, а потом (спустя длительное время, когда все уже давно забыто) добавил еще пару-тройку событий и... "наша песня хороша - начинай сначала" с наведения порядка, тупого перетаскивания событий по областям. Мы что, обезьяны, чтобы тупо перекладывать все с места на место? Ничего более умного нельзя реализовать? Понятное дело, разработчикам пока что не до таких мелочей. А нам остается ждать. И тогда уж, мы будем поддерживать области собственными усилиями только там, где платформа в принципе не способна разделить процедуры-функции по областям, ибо все "правила" в голове программиста.

23. o.nikolaev 216 19.04.17 11:20 Сейчас в теме

(21) Спасибо, Игорь. Divide et impera - разделяй и властвуй. Но как разделить правильно? Как разделить лучше? Статья - размышление на тему как точнее разделять код на ясные блоки, с помощью имеющегося в наличии инструмента - областей кода. Мнения коллег разнятся, конечно, все люди разные. :-)

10. ardn 657 27.03.17 13:50 Сейчас в теме

Поставил плюс, так как затронута важная тема.

В целом со статьей не согласен - нужно следовать стандартам уже имеющимся.

11. o.nikolaev 216 28.03.17 00:00 Сейчас в теме

Так много комментариев, спасибо всем коллегам. Начну с тех сообщений, которые были добавлены позже.

(10) Безусловно, профессиональный подход к командной разработке любого сложного продукта требует чтобы все участники следовали уже имеющимся стандартам. Но разве это утверждение запрещает рассматривать предложения по улучшению действующего стандарта?

16. unichkin 1579 28.03.17 00:56 Сейчас в теме

Про имена областей - https://its.1c.ru/db/v8std#content:2149184104:hdoc, п.1.3
Вообще любые именования методов, областей должны удовлетворять https://its.1c.ru/db/v8std#content:-2145783193:hdoc. Несмотря на "удобное" подчеркивание в области. Смысл которого мне не ясен в свете этих правил.

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

17. o.nikolaev 216 28.03.17 01:50 Сейчас в теме

(16)

А потом подумал что в 1С наверное не дураки сидят, не просто так это все.

Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-)

(16)

Имхо - разработка стандартов не то, чем надо заниматься на работе

Исключительно в нерабочее время ~~"и под хорошую закуску"~~.

18. unichkin 1579 28.03.17 09:23 Сейчас в теме

"Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-) "
- Мы теперь всю прессу стандартом считать будем?) Или только прессу от 1С? Это еще одна ваша идея?
з.ы. Ничего не имею против "изучать чужой опыт, но думать своей головой". Только я не вижу смысла воровать колизей)) Есть правила, вполне удобная база которой надо следовать. А не заниматься фигней, вводя в заблуждение неопытную публику. За публикацию - минус.

19. o.nikolaev 216 28.03.17 12:14 Сейчас в теме

(18) Роман, спасибо за высказанное суждение.

20. wolfsoft 2421 29.03.17 10:12 Сейчас в теме

Лично меня эти деления на области просто бесят. Вот такое исключительно субъективное мнение...

24. Windsor77 14 04.10.23 20:11 Сейчас в теме

(20) Поддержу, коллега. Абсолютно мозго**ная вещь, не имеющая практического смысла от слова совсем. Т.к. любые методы через F12 привык открывать и через поиск, а также окно методов модуля. Других путей нет.

25. Henkin 22.12.23 04:50 Сейчас в теме

Правила дорожного движения РФ утверждаются правительством, соответственно, изменения в них также принимаются правительством. Что произойдет, если любой водитель посчитает себя в праве ездить по своим собственным правилам?

26. o.nikolaev 216 23.12.23 20:22 Сейчас в теме

(25) ПДД обеспечивают безопасность, речь идет о жизни и смерти. Причем тут форматирование кода? Как это вообще можно сравнивать-то? :) Аналогия неуместна.

27. Henkin 24.12.23 06:39 Сейчас в теме

(26) Здравствуйте!
Извините, если обидел, но на мой взгляд тут многое зависит от степени обобщения понятий. Понятие "жизнь" можно обобщить до понятия "порядок". Понятие "смерть" можно обобщить до понятия "беспорядок". Соответственно, следование правилам, установленным неким ответственным органом - это порядок. Нарушение этих правил - это беспорядок.
С другой стороны, Ваши изменения в правила могут быть очень полезны. Но пока они не утверждены ответственным органом, они будут вносить беспорядок при Вашем взаимодействии с другими участниками процесса разработки на 1С (участниками "дорожного движения").

28. o.nikolaev 216 24.12.23 21:43 Сейчас в теме

(27) Никаких обид быть не может. Ибо уж коль скоро опубликовал что-то то будь готов к очень метким и обидным вопросам, замечаниям от неравнодушного "сообщества".
Да и вообще - будь готов ко всему :)

В том-то и дело что не претендую на место "ответственного органа". Куда уж мне. "Скромность" - мое второе имя. Эта краткая и невзрачная статейка лишь "размышление на тему" которым внезапно захотелось поделиться. Некая попытка так сказать "излить посильно" печаль от работы с кодами типовых конфигураций.

Если сказать про еще раньше, то это следствие гораздо более глубокой идеи, которую подсмотрел у гораздо более умного и талантливого человека (Барков Андрей, осс!) - как можно сильнее-сильнее стараться давать всему краткие и максимально точные имена. И чем короче - тем лучше. В идеале - одно слово.

"Изводишь единого слова ради тысячи тонн словесной руды".

Задача крайне сложная и в общем нынешнем "1С-ном мире" где "надо вчера уже было сделать доработочку клиенту" неприменима.

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