OberonCore

Выделено: viewtopic.php?p=42549#p42549

Вы использовали следующую композицию:

if cond1 then A;
if cond2 then B;
if cond3 then C;
...
Анализ поведения данной конструкции требует знания внутреннего устройства A, B и С.
Из свойств конструкции охраны я делаю вывод, что будет выполнено 0 или более блоков A..C, для которых истинна охрана.
А Вы мне во внутреннем устройстве этих A, B, C такую свинью подкладываете. Нарушаете свойства объемлющей конструкции.

Программа - это не литературный текст, извините. Оправдания вида "ну, вы читайте подряд - всё понятно ведь" не принимаются. Основная операция над программой - её развитие. Поэтому следует использовать строгий набор преобразований, который строгим образом меняет свойства (выход от постановки задачи на реализацию путём чётких шагов-схем).

Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.

Вот есть процедуры:



Я хочу выполнить вполне безобидное преобразование - добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.)

Скажите мне, я имею право это сделать? Если BlockA и BlockB - это нормальные блоки, то я имею право применить последовательную композицию и получить таким преобразованием новые процедуры, какие мне надо (с семантикой "сначала происходит BlockA, потом NewBlock")? Имею право? Да. Это право мне гарантировано свойствами структурных конструкций. Любой блок программы должен допускать последовательную композицию с другими блоками. И не только последовательную, но и вкладывание в объемлющие конструкции. И я не обязан изучать внутреннее устройство этого блока, если нет связей по потокам данных.

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

Если говорить юридически, то оказывается, что требование не использовать досрочные выходы - это не "глупая буква закона", а как раз вполне в терминах "гражданских прав", так сказать. Свобода программиста ставить EXIT-ы ограничивается в силу того, что эта свобода ограничила бы свободу других (осуществлять ЗАКОННУЮ композицию этого блока).
Технически же говоря (ну да, придираясь, но тем не менее...), это ухудшает свойства объемлющей системы в плане возможностей развития.

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

Попробовал переписать код метода (Delphi), следуя парадигме: "Нет break-ам, нет return-ам из середины" и разбив код на подфункции, оставив основную часть в виде простого цикла while.
Было: http://files.heroes35.net/html/ExprManager_OLD.html
Стало: http://files.heroes35.net/html/ExprManager_NEW.html

Смысл метода: выполнение операторов подвыражения с последующим удалением аргументов из списка и заменой оператора возвращённым значением. Пример подвыражения: a + b * 3 - 777/2. Подвыражение поступает в виде объекта-списка с распарсенными элементами. Для вышеуказанного примера:

0: TExprIdent a
1: TExprOper +
2: TExprIdent b
3: TExprOper *
4: TExprValue 3
5: TExprOper -
6: TExprValue 777
7: TExprOper /
8: TExprValue 2

После выполнения должно остаться одно значение в списке.

Определённая избыточность появляется в коде в рамках 15-20%. Но возрастает стабильность, повышается структурированность. Легче изменять отдельные части, не трогая другие. Переменные разнесены по локальным подфункциям. Код выполняется последовательно.

С уважением.

Кстати, касательно повторного использования блоков. На самом деле, не такая это утрированная ситуация. Хорошо написанный блок программы, содержащий некий паттерн, действительно может быть использован иногда в режиме "copy-paste". А если говорить о некотором генерационном случае, формальном из более высокоуровневой модели, то вообще интересный поворот получается.

Супер!

Илья, вы правы совершенно. Пока ты не можешь утверждать, что процедура - это "кирпич", то вся кухня по передаче управления неявно размазывается выходами из середины.

Пошел перечитывать Дейкстру

Мне кажется, тут речь идёт о потенциальной проблеме забытого Exit. Аналогичной проблемой страдает Сишный switch: забыли break - "провалитесь" в следующий блок.

Илья, респект! Жму руку. : ) Сам тоже обожаю такие прозрения, когда они у меня бывают.

Странное название темы "Почему программа должна быть структурной" - без знака вопроса.

Модератор выделил тему и ему вопрос - "Кому, в связи с чем, для чего надо дать ответ?".

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

Ответ на вопрос тема есть у каждого свой.

Перед программистом этот вопрос не возникает, т.к. у него есть знания и наработаная личная и в коллективе практика.
Он должен:
1. добиться реальных сроков выполнения,
2. добиться формулировки конкретного задания,
3. выполнить декомпозицию задачи,
4. решить вопросы интеграции с существующим комплексом проблемного прикладного программного обеспечения и с существующими данными,
5. должен составить алгоритм,
6. выполнить программирование,
7. выполнить отладку и тестирование,
8. предъявить и повторить этот (2-8) цикл с учетом замечаний,
9. установить созданное у пользователей,
10. решить вопросы прав доступа пользователей,
11. выпустить документацию,
12. обучить пользователей,
13. инициализировать наборы данных,
14. обеспечить восстановление при возможных сбоях,
15. демонтировать выведенное при этом из использования программное обеспечение,
16. осуществить авторский надзор.

Как видите, "Почему программа должна быть структурной" - это не проблема, о которой болит голова.

Как у преподавателей, я не знаю.

Разве ИЕЕ у Дейкстры аргумент слямзил?

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

Легкость (пере)композиции программы -- разве не облегчает цикл 2-8?

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

Хочу еще добавить:
2а. Изучить законодательные нормативные документы.
2б. Создать соответствующие структуры наборов данных.
изменить:
4. решить вопросы интеграции с существующим комплексом проблемного прикладного программного обеспечения и с существующими данными, с учетом структуры предприятия по подразделениям.

Утверждение о религиозности этой тема не предусматривало сравнение степени религиозности других тем.

Когда в типа "промышленном" софте (в частности, в open-source) сталкиваешься с такими кошмарными кусками кода, какой был разобран (и перепроектирован) в соседней ветке - viewtopic.php?p=42414#p42414, то голова ещё как болит.

Ещё, как ответ, начата вот эта тема:
viewtopic.php?f=67&t=2351

Я вернулся.


Программист должен создать ПО, иначе ему скажу "Зачем ты нужен?". Если он готов работать, то будьте уверены у него нет проблемы с Вашим вопросом "Почему программа должна быть структурной".

Уверяю Вас, когда ПО сдано, Вас поблагодарят и никто не спросит как это сделано. Вам доверяют.

Потрясающий ответ!

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

Ладно. На пользователя... забудем. Он нам доверяет, бедный. Верит, что лучше нельзя.
Ну а ну как программке расти придётся? Или когда уволимся, пусть работодатель сам думает, что делать?

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

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

Да уж... давайте по этой же логике вообще всякое профессиональное обучение отменим.

Это правда? Вот так совершенно сознательно?

По опыту общения со спецами по С++ из физиков ощущение, что они все-таки верят в то, что С++ это круто etc. Не значит, конечно, что не может быть вытеснения, так сказать, в подсознание. Но все-таки не вот так откровенно.

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

Очевидно, это не вопрос, а вариант ответа.
В таком случае лучше сюда не соваться.
Мне бывает интересно чужое мнение.
Наработанная практика имеет право на эволюцию, она не высечена в камне (впрочем, у кого как). Чтобы найти более хорошую практику, бывает полезно услышать чужое мнение, посмотреть на чужой опыт, тем более если этот опыт обращается к общезначимым основам.
Далее пункты списка объединены союзом "И" или "ИЛИ"?
Первые 8 пунктов относятся к любой сознательно планируемой деятельности, и не отражают специфику программирования вообще никак. Из вторых 8 пунктов мне за всю программистскую карьеру приходилось заниматься только пунктом 14 - обеспечением отказоустойчивости системы - но и он являлся частью техзадания, так что не должен бы стоять особняком. Пункт 9 кажется относящимся к программированию, но на самом деле не отличается от пункта 4 и заключается в создании дистрибутива (инсталляционного пакета, т.е. программы или алгоритма для установки ПО). Собственно, установку ПО пользователь производит сам либо нанимает для этого системного администратора (который вовсе не обязательно является программистом, хотя может и совмещать). Тот же системный администратор должен заниматься и пунктом 10. Пункты 11 и 12 тоже имеют крайне мало отношения к программированию. Более того, требуют совершенно иного рода знаний и умений. Демонтаж выведенного из строя ПО - спасибо, посмеялся. Важно не выбрасывать отработанное ПО куда попало и не загромождать им проходы в коридорах, а обеспечить максимальное повторное использование и утилизацию.

У некоторых программистов так бывает, что когда его нет на месте, ПО глючит и всячески отказывается работать, а когда он стоит рядом и наблюдает, то всё работает как часы. : ) Пункт 16 - это требование обеспечить "эффект присутствия"? Или это надзор за ненарушением авторских прав? Если всё же имеется в виду банальная техподдержка, то мне не понятно, чем это отличается от пунктов 7 и 8 (отладка по выявленным замечаниям).
Нет, не вижу. Именно о структурности программы у меня как программиста голова болит в первую очередь. Именно структура стоит во главе угла.

У иных программистов так бывает, что пока одно сделает, другое сломает, пока то чинит, третье перестанет работать. И так пока не найдёт какой-то хрупкий баланс, назвать который надёжной программой язык не поворачивается, даже страшно его попросить что-то доработать. А почему так происходит? Потому что сложность его программы превышает его собственные возможности восприятия и обработки. Почему? Потому, что нет структуры.
Я тоже.
Я 5 лет вёл проект, который до меня пару лет вёл другой человек. До сих пор хвалят и обращаются за добавлением новых возможностей. Да, у меня не спрашивают, как я там чего сделал. Да, мне доверяют. Но это доверие мною было заработано путём резкого повышения стабильности работы программы и полным отсутствием "исправлений результатов исправлений". Отсутствие побочных эффектов есть прямое следствие тщательного структурирования программы сверху донизу.

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

Если вам поручают нечто простое и одноразовое - сделал и забыл - то из одной точки можно экстраполировать любые графики: хоть про доверие, хоть про божественное озарение. А вот если работаешь долго над одной и той же программой, и становится она всё сложнее и сложнее год от года, то без продуманной структуры (от макро- до микроуровня, о котором данная тема) долго не протянешь.

Это как спортивная техника. Что есть признак мастерства? Постоянство. Если техника не поставлена, то постоянство становится всё призрачнее с каждой новой попыткой. Один раз можно вдарить и попасть по боксёру. Один раз можно увернуться от его удара. Но результат 12 раундов определяется прежде всего разницей в технике.

Если я правильно понял, Геннадий Тышов пытался сказать, что удельный вес собственно стиля программирования (на фоне других проблем) довольно мал. Кстати ИЕЕ это косвенно подтвердил рассказом о мотиве разработки системы на "Перл".

Ваша работа в коллективе получить дружескую оценку, как положительную так и отрицательную и безусловно вы прислушаетесь.


У Peter Almazov, вот еще одно предположение. Есть время обучения и время работы, все должно быть сделано во время. Ну, а в общем, надо учится всю жизнь.