Вход | Регистрация
    1  2  3  4   
1С:Предприятие :: 1С:Предприятие 8 общая

Короткие процедуры и функции

Короткие процедуры и функции
Я
   Конструктор1С
 
20.01.19 - 13:16
Авторы нижеперечисленных книг утверждают, что методы (процедуры и функции) по-возможности должны быть небольшими, а их название должно быть четким и точным, раскрывающим суть метода.

М.Фаулер, "Рефакторинг. Улучшение проекта существующего кода"
https://www.ozon.ru/context/detail/id/141508653/

С.Макконел, "Совершенный код"
https://www.ozon.ru/context/detail/id/138437220/

Р.Мартин, "Чистый код: создание, анализ и рефакторинг"
https://www.ozon.ru/context/detail/id/28336354/

А вы как считаете?
 
 
   Конструктор1С
 
1 - 20.01.19 - 13:19
Программы, использующие объекты, живут долго и счастливо, если методы этих объектов короткие. Программистам с малым опытом работы с объектами часто кажется, что на самом деле никаких вычислений не происходит, а программы состоят только из нескончаемой цепочки делегирований действий от одного объекта к другому. Однако, работая с такой программой на протяжении нескольких лет, вы понимаете, какую ценность представляют собой маленькие методы.

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

(с) М.Фаулер
   palsergeich
 
2 - 20.01.19 - 13:19
Так и есть.
   ДенисЧ
 
3 - 20.01.19 - 13:20
Процедура в идеале должна влезать на один экран.
   palsergeich
 
4 - 20.01.19 - 13:21
Но зарываться тоже не стоит, делать сверхдлинные стеки вызовов ради одной строчки - тоже антипаттерн.
Везде должен быть принцип разумности.
   Конструктор1С
 
5 - 20.01.19 - 13:22
Первое правило: функция должна быть компактной. Второе правило: функция должна быть ещё компактнее!

(с) Р.Мартин
   Лефмихалыч
 
6 - 20.01.19 - 13:22
(0) приведешь, может, цитаты, где Макконел и Мартин это говорят? Чо-т я не помню ничего такого вообще совсем, хотя читал обоих
   Конструктор1С
 
7 - 20.01.19 - 13:23
(4) это понятно
   Лефмихалыч
 
8 - 20.01.19 - 13:24
а, речь про количество кода внутри метода, а не про имя.
Да, все верно. Нормальная процедура/функция должна умещаться на один экран. Если не умещается, значит - бей на части. Хотя бы просто из уважения к коллегам
   Конструктор1С
 
9 - 20.01.19 - 13:24
(6) Макконела чуть сложнее процитировать, он не говорит о коротких методах в одном месте, но подводит к этому во многих местах
   Конструктор1С
 
10 - 20.01.19 - 13:27
Один из главных ментальных барьеров, препятствующих созданию эффективных методов, — нежелание создавать простой метод для простой цели. Создание метода для двух или трех строк кода может показаться пальбой из пушки по воробьям, но опыт свидетельствует о том, что небольшие методы могут быть чрезвычайно полезны. Небольшие методы обеспечивают несколько преимуществ, и одно из них — облегчение чтения кода.

(с) С.Макконел
 
 Рекламное место пустует
   Лефмихалыч
 
11 - 20.01.19 - 13:28
Мартин - писатель довольно спорный. В его книгах не меньше 50% воды просто, чтобы книжка на полке стояла и не падала. Но есть и вполне дельные мысли у него.
   Конструктор1С
 
12 - 20.01.19 - 13:52
Я ведь почему разговор завёл? Как-то в нашей 1Сной среде считается нормой сначала забубенить 30-этажный запрос, тут же на три экрана размазать сложную обработку результата запроса, сверху присыпать это дело ещё 20-30 строками кода, настраивающего интерфейс в зависимости от полученных данных, и всё это в одной процедуре со скупым названием ВыполнитьЗагрузку(). Считаю, пора уже объявить типично 1Сные методы-портянки дурным тоном и начать за них хлестать линейкой по рукам, как и за запросы в цикле, и прочий говнокод.
   palsergeich
 
13 - 20.01.19 - 14:01
(12) В каждом конкретном случае - решается индивидуально.
Пригать по микрофунуциям типа -
СоздатьПараметрыЗапроса()
ТекстЗапросаДляЗагрузки()
ОбъектЗапросДляЗагрузки()
ИсполнитьЗапрос()
ОбработатьРезультатЗапроса()
Тоже может быть то еще приключение.
В каждом конкретном случае - индивидуально, если мне понятен текст программы и он целостен - дробить не имеет смысла.
Если есть скрытые зависимости - тут без дробления никуда  не деться.
   palsergeich
 
14 - 20.01.19 - 14:02
(13) особенно если в низ идет дальнейшее дробление.
Где то на 10 по глубине в стеке забываешь зачем сюда попал.
   palsergeich
 
15 - 20.01.19 - 14:05
Это творческая профессия.
И есть рекомендации, которые надо знать.
В каждой конкретной реализации надо взвесить за и против и попытаться через призму своего опыта выбрать наилучшее решение.
   palsergeich
 
16 - 20.01.19 - 14:13
Например на текущей работе у меня сейчас творческий конфликт, на стадии обострения.
Мне не нравится та реализация, которую меня просят сделать, я вижу что она приводит к dependency hell, я делаю совсем по другому, потому что видел к чему это ведет. По времени и сложности - одинаково, времени на реализацию более чем достаточно. Пока терпят, но мне это уже не нравится - команда совершенно не воспринимает чужое детально аргументированное мнение.
Но если будет прямой приказ родить говно без объективной причины, я просто покину текущего работодателя.
   Asmody
 
17 - 20.01.19 - 14:48
Код функции должен умещаться в один экран. В один экран терминала 80х25.
   michael512
 
18 - 20.01.19 - 15:05
теперь я понял, почему я генерирую адов говнокод с очень длинными функциями на 5-6 экранов FullHD. Раньше удивлял чужой код на яве/си/си++, почему у них функция в функции, функции, функции, а там уже черт разбире, почему туда зашел...
на 1С я реализую поток сознания, потом забываю/забиваю с разбиением, потому что это ИМХО слабодисциплинирующий ЯП, с большими допусками.
на яве (делаю андроид проэкты) все разбито по классам и функциям, иногда в классе 20-30 методов и свойств, несложный проект состоит из 10+ классов
   ДенисЧ
 
19 - 20.01.19 - 15:06
(17) 72*24
   Конструктор1С
 
20 - 20.01.19 - 15:08
(13) дробить всё по микрофункциям не надо. Имя метода должно четко отражать его цель, чтобы сразу было понятно, что делает этот метод. Тогда не придется проваливаться в каждую процедуру/функцию без надобности. Например, есть функция:

Функция РассчитатьНДФЛПоСотруднику(Сотрудник, Параметры)
    
    НДФЛ = 0;
    
    ЯвляетсяРезидентом = СотрудникЯвляетсяРезидентомРФ(Сотрудник);
    
    Если ЯвляетсяРезидентом Тогда
        
        НДФЛ = РассчитатьНДФЛПоСтавке13(Сотрудник, Параметры);
        
    Иначе
        
        НДФЛ = РассчитатьНДФЛПоСтавке30(Сотрудник, Параметры);
        
    КонецЕсли;
    
    Возврат НДФЛ;
    
КонецФункции

в данной функции всего один блок "Если" и вызов трёх функций. Из кода сразу становится понятно, что он делает. Функция довольно короткая. Казалось бы, что можно было содержимое функций РассчитатьНДФЛПоСтавке13() и РассчитатьНДФЛПоСтавке30() впихнуть прямо здесь. Но! Тогда самодокументируемость кода снизилась бы

Функция РассчитатьНДФЛПоСотруднику(Сотрудник, Параметры)
    
    НДФЛ = 0;
    
    ЯвляетсяРезидентом = СотрудникЯвляетсяРезидентомРФ(Сотрудник);
    
    Если ЯвляетсяРезидентом Тогда
        
        // тут много кода

        //...

        
    Иначе
        
        // тут много кода

        //...

        
    КонецЕсли;
    
    Возврат НДФЛ;
    
КонецФункции

Допустим, я изучаю алгоритм расчета НДФЛ по ставке 30%. Если будет первая функция, то мне понадобится секунда, чтобы пробежать глазами 3 строки и нырнуть в нужную мне функцию РассчитатьНДФЛПоСтавке30(). А если бы вместо вызова этих функций было по 20-30 строка кода, как во второй функции? Тогда я сначала потратил бы время на просмотр первого блока кода (между Если и Иначе), и только потом, поняв логику кода, обнаружил что мне нужно идти дальше. Считай затрачено дополнительное время и лишние мыслительные ресурсы.
   Йохохо
 
21 - 20.01.19 - 15:16
(20) когда ты "нырнешь" в РассчитатьНДФЛПоСтавке30 там 10 функций из четырех модулей будут собирать запрос и появится желание почитать умные книжки про фанатизм
   Конструктор1С
 
22 - 20.01.19 - 15:16
+(20) тут можно возразить, что достаточно добавить под "Если" и "Иначе" по комментарию, и сразу станет всё понятно. Так, да не совсем так. Даже если я наткнусь на комментарий, мне всё равно придётся немного напрячь своё внимание и потратить немного времени, чтобы найти, где заканчивается ознаменованный комментарием участок кода и начинается другой. По сути я затрачу немного своих интеллектуальных ресурсов на тот код, который мне в принципе не нужен.
К тому же, с комментариями часто также творятся ахтунги
   Конструктор1С
 
23 - 20.01.19 - 15:30
(21) если эти функции будут четко описывать возвращаемые ими значения, то в этом нет ничего плохого. При правильном подходе методы выступают своего рода оглавлением, как в книге. По ним ты быстро найдёшь тот код, который тебе нужен.
А теперь представь себе метод на 5 тысяч строк. Это всё равно что листать книгу без оглавления. Нужный текст книги может размещаться на 51 странице, но ты об этом не знаешь, поэтому тебе придётся перечитать лишних 50 страниц, пока найдёшь нужную строчку. Читать 50 страниц ради одного предложения как-то перебор.
Подобно книге без оглавления, громоздкая функция заставит тебя просмотреть её всю. Причем сделаешь ты это несколько раз. Первый раз ты будешь вчитываться в функцию чтобы понять, чего она там делает. А во второй раз ты снова будешь перечитывать эту же функцию, чтобы найти ту строчку кода, которая тебя интересует. На двух прочтениях дело может не закончиться. Скорее всего тебе придется крутить колёсико мышки туда-сюда несколько раз. Вот тебе и польза от компактных методов - не приходится созерцать лишний код.
   Конструктор1С
 
24 - 20.01.19 - 15:37
Я видел громоздкие процедуры/функции, авторы которых безолаберно подходили к именованию переменных и не считали нужным писать комментарии. Работать с такими методами это адский ад. Сначала два часа сидишь выясняешь, чего там в этом коде делается, на три раза прогоняешь всё отладчиком, чтобы понять логику. Вносишь маленькие изменения... и потом ещё три часа отлаживаешь этот метод. Ибо изменение одной строки кода привело к тому, что всё посыпалось в трёх других местах. Было бы всё по-человечески, понадобилось бы 5 минут, а так ушло 5 часов.
   vi0
 
25 - 20.01.19 - 17:11
в 1с использование областей позволяет улучшить читабельность без увеличения кол-ва процедур
   VladZ
 
26 - 20.01.19 - 17:13
(0) Огромные процедуры и функции - как чукотские песни: нет в них ни конца ни края... И общую логику понять очень сложно..
   Cyberhawk
 
27 - 20.01.19 - 17:51
"название должно быть четким и точным, раскрывающим суть метода"// 100%

"по-возможности должны быть небольшими"// По возможности
   etc
 
28 - 20.01.19 - 18:20
Вот кто разработчиков типовых покусал. Восприняли рекомендации как устав. И получилось как описано в (18): "функция в функции, функции, функции, а там уже черт разбире, почему туда зашел..."
   Конструктор1С
 
29 - 20.01.19 - 18:20
(25) согласен. Но всё-таки области нельзя рассматривать как замену выделению процедур/функций.
1. При вызове метода, передаваемые в метод параметры могут давать дополнительную поясняющую информацию. В то же время имя области не поясняет, с какими переменными работает код, спрятанный внутри этой области. Может появиться соблазн заглянуть внутрь области, когда будь на её месте процедура, желания не возникло бы
2. Если области по-умолчанию не сворачиваются, то область будет выполнять скорее функцию комментария, чем "указателя в оглавлении книги". Стандартно у всех области не сворачиваются, этот параметр нужно включать вручную.
3. Области позволяют сделать код легче воспринимаемым, но не позволяют сделать его более гибким. Если громоздкую процедуру исполосовать областями, она останется всё той же громоздкой процедурой, со всеми вытекающими. А компактные методы привлекательны ещё и тем, что такой код легче дорабатывать
   vi0
 
30 - 20.01.19 - 18:28
(29) да никто и не спорит
зы: термин "метод" не совсем корректно используешь
   etc
 
31 - 20.01.19 - 18:29
"В старых языках программирования вызов процедур был связан с большими накладными расходами, которые удерживали программистов от применения маленьких методов"

А что чтото кардинально изменилось со времен когда в процедуру параметры передавали через стек? Или автор сего труда хочет сказать что "гигагерцы всё простят"?
   Конструктор1С
 
32 - 20.01.19 - 18:34
(28) в типовых беда в том, что они пишутся как бы модульно, в не поддерживающей модульность системе. Одни и те же куски используются в различных конфигурациях. Это приводит к появлению "защитного программирования" (проверяется, есть ли определенный объект, какое имя конфигурации, какая версия и пр.), последнее уже и выливается в лишние петляния по функциям

(30) почему не правильно? Насколько я знаю, метод это общее название для процедур и функций
   Cyberhawk
 
33 - 20.01.19 - 18:35
(29) "Стандартно у всех области не сворачиваются, этот параметр нужно включать вручную" // Стандартно все свернуто
 
 
   Лефмихалыч
 
34 - 20.01.19 - 18:41
(31) автор хочет сказать, что сейчас ресурсов достаточно, чтобы не приносить сопровождаемость кода в жертву производительности.
   d4rkmesa
 
35 - 20.01.19 - 18:51
(12) Ну вот в БСП частенько стек из 20 вложенных функций, мало вам? Надо 50?
   Sserj
 
36 - 20.01.19 - 18:59
(31) Ну вообще, не применимо к 1С конечно, но компиляторы достаточно умные что бы на месте вызова функции при возможности впихнуть тело самой функции, так называемые inline вставки.
   Конструктор1С
 
37 - 20.01.19 - 19:08
(35) не, мне много. Вложенность функций не должна вредить их восприятию
   Конструктор1С
 
38 - 20.01.19 - 19:10
(33) разве? Вроде по-умолчанию области не сворачиваются, также как циклы и условия
   vi0
 
39 - 20.01.19 - 19:12
(32)
> Насколько я знаю, метод это общее название для процедур и функций.
Нет.
   Garykom
 
40 - 20.01.19 - 19:13
(35) Это стандартная проблема функционального программирования по сравнению с ООП.
   Конструктор1С
 
41 - 20.01.19 - 19:15
(39) кхм. А как правильно тогда?
   ДенисЧ
 
42 - 20.01.19 - 19:18
(41) Функция/процедура.
Обычно функция. Если хочешь подчеркнуть, что она не возвращает значение - то процедура.
А метод - это процедура(функция)-член класса.
   Garykom
 
43 - 20.01.19 - 20:39
(42) В каком то смысле в платформе 1С функции/процедуры находятся или всегда в модуле (общем, формы, объекта или менеджера).

Так что можно считать что модуль ~ класс, ведь обращение извне идет через ".".
Короче функция/процедура это де юре метод модуля.
   vi0
 
44 - 20.01.19 - 20:47
(43) ты тока в приличном обществе такое не говори)
   dmpl
 
45 - 20.01.19 - 20:54
(17) У нас процедуры :p

(24) 3000 рэ за час. Лучше срубить 5 часов.
   palsergeich
 
46 - 20.01.19 - 21:32
(29) Ковырял я как то модуль формы на 150 к строк.
Трешман еще тот, синтакс помошник - отключал иначе работать нельзя было, и то в одном случае он все равно срабатывал и где то на минуту зависон.
Ну дык вот к чему я это - на исправление 2 строчек кода у меня ушел месяц.
Это было мое задание на ИС, то есть предпологалось что это займет 3 месяца.
Потом конечно по общим модулям раскидали, что возможно, стало лучше.
   palsergeich
 
47 - 20.01.19 - 21:38
К чему я это.
Имея Легаси - будь готов за него платить.
   palsergeich
 
48 - 20.01.19 - 21:41
https://habr.com/ru/post/429946/ просто оставлю это тут.
   PR
 
49 - 20.01.19 - 23:27
(0) Масса врачей считает, что нужно чистить зубы
Ну и, чтобы два раза не вставать, многие считают, что лучше быть здоровым и богатым, чем бедным и больным

А вы как считаете?
 
 Рекламное место пустует
   vde69
 
50 - 21.01.19 - 00:11
(3) на 1 экран не возможно впихнуть текст запроса на 5 экранов, а дробить текст запроса - бред...

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

ну и тут есть еще нюансы (про который напрочь забыли разработчики типовых):
1. каждый законченный модуль/функционал должен иметь четко описанный программный интерфейс (это 1с пытается делать, но как-то нелепо)
2. глубина стека вызова между различными программными  интерфейсами (как сверху вниз так и по горизонтали) не должна быть большой (в идеале 3..4), а вот тут 1с как-то вообще все забило...
   Ник080808
 
51 - 21.01.19 - 00:17
(0) Естественно. Просто 1сники в большинстве своем не работают с конфигцрацией в целом - это или точечное допиливание мелких доработок в типовой, или переписывание в команде кусочка типовой. И получается когда идентичный кусочек кода в 20 строк встречается в 30 местах. А потом, когда нужно внести изменение в логику этого кода, ты тратишь неделю на поиск этих кусочков и проверку ничего не поламалось ли после твоих изменений, вместо пяти минут, ты понимаешь, что разработчики типовых выросли, а ты нет.
   Ник080808
 
52 - 21.01.19 - 00:23
(50) "(0) процедура должна быть закончена по смыслу и понятна названа, все остальное - пофигу... " ну вот 1с 77, процедура формирования отчета СформироватьОтчет, закончена по смыслу и понятно названа, вот только содержит в себе 14 000 строк кода, из которых 10500 это дубли кода, удаление которых не повлияли никак на функционал. еще около 1000 строчек кода это заполнение полтора десятка идентичных по своей структуре таблиц значений. Добавление одной колонки в таблицу значения требовало до 8 часов затрат. Вынос заполнение строки тз в отдельную процедуру с переписыванием вызовов сократило это время до получаса.
   Конструктор1С
 
53 - 21.01.19 - 04:16
(48) слышал, что со всякими там SAP что-то подобное. Их писали несколько поколений программистов, и теперь там ряд участков, которые просто нельзя менять.
   Злопчинский
 
54 - 21.01.19 - 06:33
(24) безалаберно писать "безолаберно"
Отсюда и начинаются всякие потуги писать читаемый код. Если код написан грамотно - то он и читается норм.
Убивают клюшечники, которые пишут поток сознания, функции и процедуры не отбиты хотя бы одной пустой строкой. Код вообще как спагетти, ни пробелов ни разбиения на смысловые блоки. Уроды.

Недоделанные отчёты - не беда. Главное - доделывайте детей. А то они вырастают и приносят недоделанные отчёты. И никак не разорвать этот порочный круг.
   Конструктор1С
 
55 - 21.01.19 - 07:05
(54) грамматические ошибки далеко не главная беда в написании кода. Можно обозвать процедуру орфографически правильно, но совершенно не внятно. .Но если процедура названа четко и конкретно, отражает суть выполняемых ею действий, даже пускай в имени содержатся орфографические ошибки, надобность "провалиться" в неё просто отпадает.

Вариант №1:

ОтсортироватьМассивПоВозрастанию(Массив);

сразу понятно, что в данной процедуре происходит сортировка значений массива. В 99 случаев из 100, при анализе кода процедуру можно пропустить. Даже если в имени процедуры будут орфографические ошибки (ОтсартероватьМасивПоВозростанию()), предназначение процедуры не станет менее понятным. Ну да, будет резать глаз, но на легкость восприятия кода это почти не повлияет.

Вариант №2
УпорядочитьКорректно(Массив);

Что упорядочить? Что подразумевается под "корректно"? Будут упорядочены значения массива или массив служит вспомогательным параметром? И ещё ряд вопросов. Хотя имя процедуры написано без ошибок, даже грамотными словами, оно совершенно не отражает цели процедуры. Придётся провалиться в эту процедуру, чтобы понять логику её работы
   dmpl
 
56 - 21.01.19 - 07:09
(55) А теперь попробуйте сделать что-нибудь реальное в 1С - там названия будут как Л.Н. Толстого предложения. Опять же, непонятно, по какому полю сортируется массив, так что провалиться все равно придется.
   Йохохо
 
57 - 21.01.19 - 07:18
(55) ОтсартероватьМасивПоВозростанию код такой процедуры придется вычитывать в 99 случаях из 100. Потому что она может вернуть ТЗ, там может быть .Записать(), преобразованы типы и вообще что угодно. Всё пропорционально, сколько человек потратил усилий на имя, столько же и на код. Как человек задал вопрос, настолько он ему и важен.
   Конструктор1С
 
58 - 21.01.19 - 07:33
(56) длинные названия процедур это не проблема. Главное, чтобы имя процедуры отражало её суть. Разумеется, длина имени должна находиться в разумных пределах

(56) если код написан не говнокодером, то проваливаться не придется. Название процедуры и её единственный параметр и так рассказывают, что она выполняет.
Но если на данный момент ты читаешь говнокод, в котором процедура обозвана ВыполнитьДействия(), а там 3 тысячи строк кода, 10 различных логических действий, мёд, говно и пчёлы, то тебе придется заглянуть в подобную процедуру. Ибо в говнокодерстве принято выполнять в одной процедуре что угодно и как угодно, без какого-либо логического разграничения, а процедуры именовать скудно.

Повторюсь, хороший код, он как оглавление в книге. По оглавлению книги ты быстро найдешь интересующую тебя страницу, а по удачным названиям процедур можно быстро найти интересующий тебя кода, либо понять логику алгоритма.
   Конструктор1С
 
59 - 21.01.19 - 07:34
+ а орфографические ошибки могут происходить машинально. Очепятки там всякие, например
   dmpl
 
60 - 21.01.19 - 07:38
(58) Так по какому полю массива выполняется сортировка?
   Конструктор1С
 
61 - 21.01.19 - 08:02
(60) скорее всего в массив переданы данные примитивного типа. Дальше всё очевидно.
   ADirks
 
62 - 21.01.19 - 08:11
Самая главная проблема со всеми этими (обычно весьма разумными) правилами в том, что люди не понимают, что и зачем делают. Вследствие чего воспринимают писанные правила так, что авторы в гробах переворачиваются.

Добавлю также правило от себя, про которое почему-то никто не пишет:  Без фанатизма.
   Йохохо
 
63 - 21.01.19 - 08:20
попалось от того же Мартина
— Almost all the successful microservice stories have started with a monolith that got too big and was broken up
— Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious troubl.
Вполне переносится по смыслу на трехстрочные функции. Так что сам Мартин живет без фанатизма
   APXi
 
64 - 21.01.19 - 09:04
(60) У массива одно поле.
   laby1
 
65 - 21.01.19 - 09:07
(0) Согласен.
   dmpl
 
66 - 21.01.19 - 09:37
(61) В случае 1С там почти гарантировано не примитивный тип. Зачем сортировать строки или числа без привязки к чему-либо?

(64) Только это поле сортировать бессмысленно.
   Cyberhawk
 
67 - 21.01.19 - 10:42
(38) За последний месяц-два несколько раз ставил с нуля платформы-сервера. Циклы и условия не сворачиваются, а вот области везде в открываемых конфигурациях (в модулях) _вроде_ были свернуты (т.к. Я запомнил стремное чувство от того, что приходилось их разворачивать в каждом модуле).
Но вот сейчас проверил в очередном "нулевом" конфигураторе и походу ты прав - области не свернутые)
   Tonik992
 
68 - 21.01.19 - 10:44
(62) >> что люди не понимают, что и зачем делают
Откуда у вас такие выводы за всех? Это обман в явном виде.
   Cyberhawk
 
69 - 21.01.19 - 10:44
(46) Самописка какая-то или в тиражной (типовой / отраслевой) конфе такое было?
   Cyberhawk
 
70 - 21.01.19 - 10:49
(66) "зачем сортировать", "бессмысленно" - сортировать надо чтоб обойти потом конечно же
   palsergeich
 
71 - 21.01.19 - 10:50
(69) самописка, дикий 15 летний Легаси, который построчно был переведен с 77 на УФ.
   Asmody
 
72 - 21.01.19 - 10:56
Знакомство с парадигмой функционального программирования помогает переосмыслить подходы и в "традиционном" императивном программировании. В частности, помогает понимание "чистых" функций и "программа как поток данных". В первом случае ты добиваешься декомпозиции до неких "атомарных" операций, по принципу "одна функция - один результат". Во втором - начинаешь смотреть на программу не как на последовательность шагов, но как на некий массив данных, обрабатывая который, приближаешься к результату.

Но это не отменяет необходимости понимать, что ты делаешь вообще, в каких случаях такой подход применим, а в каких - нет.
   Tonik992
 
73 - 21.01.19 - 10:56
(56) А как по вашему правильно - дать название методу в форме Льва Толстого, чтобы оно было понятно как вам так и другому, либо сократить название до минимума, а вместе с этим и скрыв главное намерение и цель функции?
Не надо бояться больших названий. У меня таковые очень редко бывают
   Asmody
 
74 - 21.01.19 - 10:58
(73) Главное, чтобы название процедуры не было больше самого кода процедуры :)
   APXi
 
75 - 21.01.19 - 11:02
(66) Ну почему же бесполезно. Может там номера строк, с которыми потом нужно что то сделать. Но обсуждать сферического коня в вакууме нет смысла.
Везде нужно соблюдать золотую середину и думать прежде чем делать.
   Конструктор1С
 
76 - 21.01.19 - 11:15
(66) это был лишь условный пример. Тем не менее, я встречал подобное, кажется даже в типовой конфигурации. Массив загружается в список значений, список сортируется по значению, обратно выгружается в массив.
   ам794123
 
77 - 21.01.19 - 11:48
// Как правильно писать    код?

    //

    // ТАК:

    
    
    Выборка = Запрос.Выполнить().Выбрать();
    
    
    Пока Выборка.Следующий() Цикл 
        
        УсловиеВыполнено = ПроверитьУсловие();
        
        Если УсловиеВыполнено Тогда 
            
            // здесь много кода записанного через строчку, очень-очень важного и сложного

            ...
            
                        
            
        Иначе
            
            // здесь какой-то код, тоже через две строки, хотя простого, но очень важного
            ...
            
            
            
        КонецЕсли;
        
        
    КонецЦикла;

    
    // ИЛИ ТАК:    

    
    Выборка = Запрос.Выполнить().Выбрать();
    Пока Выборка.Следующий() Цикл 
        Если УсловиеВыполнено() Тогда ДелаемЧтоТоВажное(); Иначе НичегоНеДелаем(); КонецЕсли;
    КонецЦикла;
   vi0
 
78 - 21.01.19 - 12:02
(77)
так, в одну строку, точно делать не нужно:
Если УсловиеВыполнено() Тогда ДелаемЧтоТоВажное(); Иначе НичегоНеДелаем(); КонецЕсли;
   bolobol
 
79 - 21.01.19 - 12:04
Вот так:

Выборка = Запрос.Выполнить().Выбрать();
    Пока Выборка.Следующий() Цикл 
        Если УсловиеВыполнено() Тогда
            Делаем...
            Делаем...
            Делаем...
            КонецЭкранаБлизокПередаёмПродолжениеВыполненияДелВПодпрограмму(Выборка, Объект, ПеременнаяПроцедуры1, ПеременнаяПроцедуры2, ПеременнаяПроцедуры3, ПеременнаяПроцедуры4, ПеременнаяПроцедуры5, ПеременнаяПроцедуры6, ПеременнаяПроцедуры7, ПеременнаяПроцедуры8... ПеременнаяПроцедурыН);
        Иначе
            НичегоНеДелаемВОтдельнойПодпрограммеТКУжеБылДостигнутКонецЭкрана();
        КонецЕсли;
    КонецЦикла;
   OldCondom
 
80 - 21.01.19 - 12:08
Недавно надо было отловить ошибку в БП3 по имущественному налогу. В рот мне ноги... Это пишут не люди.
   bolobol
 
81 - 21.01.19 - 12:12
"..., а БОГИ!" - хочется добавить)
   Tonik992
 
82 - 21.01.19 - 12:38
(77) Иногда второй вариант предпочтительней.
К примеру, есть какая-то функция общего назначения, называется
ЭлементЕстьВСтруктуре(Структура, Элемент), возвращает Булево.

А в конкретной строке некоего модуля X, истинность ЭлементЕстьВСтруктуре() будет означать, что "Склад разрешен".

И тогда правильнее было бы результат ЭлементЕстьВСтруктуре() разместить в переменной
СкладРазрешен = ЭлементЕстьВСтруктуре(), чтобы результат функции был понятен.
   Конструктор1С
 
83 - 21.01.19 - 12:38
(77) второй вариант будет получше. Но в одну строку писать логические условия это зло. Во втором варианте возможно будет соблюдён ещё один важный принцип: одна процедура для одной цели. Когда процедура делает что-то одно, ей гораздо легче выбрать хорошее имя. Да, среди 1Сников этот принцип не особо приветствуется, они привыкли в одной процедуре и данные файла прочитать, и проверку данных провернуть, и в таблицы данные подгрузить, и в конце ещё интерфейс программно поднастроить.

(79) это уже говнокод. Когда процедуры компактные и конкретные, в них просто нет зоопарка из переменных.
   bolobol
 
84 - 21.01.19 - 12:42
(83) Не видел такого кода, где нет зоопарка из переменных. Видимо, сложнее "СкладРазрешен = ЭлементЕстьВСтруктуре()" вы кода не видели. Если тема об этом, о том как прочитать "СкладРазрешен = ЭлементЕстьВСтруктуре()" и понять написанное - увы.
   ADirks
 
85 - 21.01.19 - 12:50
(83) >ещё один важный принцип: одна процедура для одной цели

я бы сказал, не "ещё один ...", а "_ОЧЕНЬ_ВАЖНЫЙ_ ..."
ну и цель цели тоже рознь. Очень часто программисты не задачу решают, а код пишут. Отсюда и названия методов, как в (79). И ОтсортироватьМассивПоВозрастанию() - из той же оперы.
   Ник080808
 
86 - 21.01.19 - 12:53
(84) так в этом и весь вопрос, что бы разложить сложный код с зоопарком переменных на кучу простых функций типа "СкладРазрешен = ЭлементЕстьВСтруктуре()", тогда уменьшается объем кода и увеличивается его управляемость.
   Вафель
 
87 - 21.01.19 - 12:56
однако другая сторна - это стек вызовов на 500 позиций.
найти тут ошибку очень не просто.
Да и понять что же делает каждый из 500 объектов тоже
   Ник080808
 
88 - 21.01.19 - 12:57
(87) "Да и понять что же делает каждый из 500 объектов тоже" так и идет обсуждение, что для понимания нужно правильно звать методы
   Tonik992
 
89 - 21.01.19 - 13:04
(88) Ну и использовать методы не для того, чтобы только соблюсти правило "влезо на экран". Суть методов не в том, как в (79) описано. Чисто ради:
СуперСложнаяСортировкаЧастьОдин()
....
СуперСложнаяСортировкаЧастьДва()

так не надо.

В добавок ко всему, когда я изменяю функцию/процедуру, то я немного абстрагируюсь от окружающего кода. Если бы всё было в одной процедуре, то сможешь ли ты с первого раза ответить на вопрос:
"Где-нить эта переменная еще будет использовать?" Как в (86) сказали, управляемость намного выше становится.

bolobol не понимаю ход твоих суждений.
   Вафель
 
90 - 21.01.19 - 13:05
(88) само по себе 500 методов - это 500 методов, вне зависимости от назваания
   Ник080808
 
91 - 21.01.19 - 13:09
(90) так не все ж 500 одновременно используются
   Вафель
 
92 - 21.01.19 - 13:10
(91) вызов конечной функции тянет за собой стек вызовов всех этих 500
   Вафель
 
93 - 21.01.19 - 13:13
   Ник080808
 
94 - 21.01.19 - 13:15
(93) дык, это если они у тебя вложенные одна в другую
А если у тебя Процедура ЗабубенитьСчастье()
В ней Если СчастьНет() Тогда
СделатьСчастье();
Иначе ОставитьНесчастливым() КонецЕсли; то у тебя в стэк попадет только одна из веток. Уже не 500, а 250 функций/процедур)
   ildary
 
95 - 21.01.19 - 13:25
(93) авторы типовых видели этот скриншот и похоже решили "догнать и перегнать".
   Cyberhawk
 
96 - 21.01.19 - 14:07
Уже было? http://govnokod.ru/24224
   Tonik992
 
97 - 21.01.19 - 14:19
(96) Должен когда-нибудь выйти в люди один из разработчиков ЗУП и рассказать нам про выбранную архитектуру кода. Обосновать.
   Asmody
 
98 - 21.01.19 - 14:21
(97) Они не могут выйти - они к лавкам прикованы.
   Конструктор1С
 
99 - 21.01.19 - 14:25
(84) а я видел. И стараюсь писать такой
   Конструктор1С
 
100 - 21.01.19 - 14:35
(90) ничего плохого в 500 методов нет, если они хорошо документированы и в них легко ориентироваться.  В то же время, громоздкие методы всегда сложны по структуре и трудно воспринимаются
  1  2  3  4   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует