Оператор GOTO: за и против

Люди, по ходу, газет не читают:
Оператор GOTO в языках высокого уровня является объектом критики, поскольку чрезмерное его применение приводит к созданию нечитаемого «спагетти-кода». Впервые эта точка зрения была отражена в статье Эдсгера Дейкстры «Доводы против оператора GOTO», который заметил, что качество программного кода обратно пропорционально количеству операторов GOTO в нём. Статья приобрела широкую известность как среди теоретиков, так и среди практиков программирования, в результате чего взгляды на использование оператора GOTO были существенно пересмотрены. В своей следующей работе Дейкстра обосновал тот факт, что для кода без GOTO намного легче проверить формальную корректность.

Код с GOTO трудно форматировать, так как он может нарушать иерархичность выполнения (то есть парадигму структурного программирования), и потому отступы, призванные отображать структуру программы, не всегда могут быть выставлены правильно. GOTO также аннулирует многие возможности компилятора по оптимизации управляющих структур

Доводы против оператора GOTO оказались столь серьёзны, что в структурном программировании его стали рассматривать как крайне нежелательный

Начало тут

0

Сообщение от CoderHuligan Эти состояния есть константы, а не флаги.

Очень интересно, как вы в одно единственное состояние запихнёте «персонаж выбран | не выбран», «у персонажа есть предмет в инвентаре | нет предмета» и прочие вещи?

0

Сообщение от CoderHuligan Дейкстра в конце концов также пришел к этому выводу

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

Сообщение от CoderHuligan А этих состояний может быть десятки и сотни.

Ты не учитываешь три вещи:
1) Код не обязательно должен иметь строгую древовидную структуризацию. А то про что ты лопочешь
эффективно и целесообразно только в данном виде оптимизации. Остальное - это сраный макаронинг.
2) Он должен быть дополняем(желательно без правки половины условий)
3) Фактор по состояниям может быть не один. В итоге количество комбинаций считается как
суммарный перебор уникальных комбинаций этих факторов. И каждый раз где код схож и по сути
не нуждается в дублировании тебе придётся его дублировать - а это жопа.

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

Что не убедил?

Сообщение от CoderHuligan Флаги это - проверки, всегда проверки этих флагов. На проверки переменных уходит время.

Условия - тоже проверки, на условия тоже уходит время. Ты предлагаешь отказаться от проверок условий?
Жесткачишь бро!))) Ты знаешь как в бейсике сделаны условия? И почему именно так?
Это не классические асмовые условия, туда можно засунуть переменную(даже не целочисленную),
по итогу оно всё сводится к целочисленной(неявное преобразование типа) и выполняет проверку
условия (переменная = TRUE)**, причём для QB это делается всегда.
JMP и любые Jxx - представь себе это тоже время, любая инструкция это время, т.е. выбор ветвистых
ветвей - это тоже время, а ещё они сбрасывают кешированный пул команд в конвеерах ЦП и это время
становится ещё большим временем. Боже как это всё страшно.
Вообще коли такие заморочи в голове водятся, то можно вообще не садиться программировать - утонешь в них.
И самое главное, нормальный программист всегда понимает по скорости что, где и чем он жертвует
в обшей массе и в общем мясе этих перемалывающихся инструкций. И самое забавное что сейчас
мы не говорим даже об 0,01% скорости на участках где вся скорость внтури блоков или где используется
например синхронизация по таймеру. Будет ли адекватный программист короткие и важные для задачи циклы
писать на бейсике да ещё и переливать из пустого в порожнее с флагами? Конечно нет, разумеется,
если никто ему мозги не промыл кроссплатформенностью и желанием угодить всей братии пользователей(как
будто на каждой платформе нет своей братии программистов угождальщиков).

И одно дело андроид со своими java лопухами, тут хотя бы масса пользователей и совсем другое - linux и mac.
Как показала практика мало того что нецелесообразно, так ещё и не тестируют, от слова совсем.
Редкие ответственные люди этим занимаются, остальные пребывают в иллюзиях о толпах пользователей.
О геморах портажа и тестировании мало кто реально заботится.

** в бейсике(QB) TRUE - есть диапазон целого числа, на практике - всё что не является нулём, формально же
по документации -1 это TRUE, а 0 это FALSE.

0

Сообщение от Quiet Snow по документации -1 это TRUE, а 0 это FALSE.

А кто‐то считает, что true — это единица.
Поэтому я никогда не сравниваю результат с true, а только так.
Проверка на истину:
Проверка на ложь:

1

Сообщение от Замабувараев Очень интересно, как вы в одно единственное состояние запихнёте «персонаж выбран | не выбран», «у персонажа есть предмет в инвентаре | нет предмета» и прочие вещи?

Дело вот в чем.. При обычном программировании мы смешиваем флаги-события, флаги-параметры и флаги-режимы в одно кипучее месиво.. Что за что отвечает с первого взгляда понять невозможно. Если же мы четко разграничим сферу ответственности, то все становится сразу более ясным.
"Выбран/не выбран" - это событие. "У персонажа есть предмет" - это булевый параметр. Допустим, событие произошло, персонаж выбран. Тогда это событие поступает на вход логического блока, который переключает состояние персонажа, или не переключает, а изменяет параметр. Персонаж находится в движении - это состояние, за которое отвечает логический блок (особо устроенная отдельная функция). Персонаж стоит - это состояние персонажа, одно из многих возможных. Так вот, при традиционном подходе за режим-состояние также отвечает флаг, в то время как надо, чтобы за это отвечала одна единственная переменная, в которой будет записано: персонаж стоит/идет. И в зависимости от того, что в этой переменной находится, логический блок переходит в это состояние, в котором и происходит конкретная работа: вызовы конкретных действий в зависимости от входных условий-событий и параметров.
Надеюсь внятно объяснил.
То есть имеем отдельно - логику, отдельно действия, отдельно события, отдельно параметры.

Сообщение от Quiet Snow Даже ты, прости меня господи, не имея за спиной нормальных проектов, программируешь лучше, чем этот губошлёп.

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

Сообщение от Quiet Snow Условия - тоже проверки, на условия тоже уходит время. Ты предлагаешь отказаться от проверок условий? Жесткачишь бро!)))

Нет конечно. Я предлагаю загнать их по своим нишам-состояниям, и вот там они пусть пасутся. Причем когда они собраны вместе становится легко оптимизировать код проверок, то есть можно избавится от бесконечных if/else просто обеспечив вызов функций/действий по таблице их указателей в зависимости от входных событий.
И вместо лесенок из условий оставить одно.

Сообщение от Quiet Snow Он должен быть дополняем(желательно без правки половины условий)

Это очень сложно делать когда все перемешано в коде.

Сообщение от Quiet Snow 3) Фактор по состояниям может быть не один. В итоге количество комбинаций считается как суммарный перебор уникальных комбинаций этих факторов. И каждый раз где код схож и по сути не нуждается в дублировании тебе придётся его дублировать - а это жопа.

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

Сообщение от Quiet Snow И вот объясни, на кой хрен мне с этим связываться в программе, где, к примеру, движок уже написан и оптимизирован, а вся работа с флагами состояний идёт на самом высоком уровне.

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

Добавлено через 4 минуты
Ну и логический блок должен ИМХО работать на goto, хотя можно и на обычных условиях или переключатель через цикл. В первом случае это будет быстрее и понятней..

0

Сообщение от CoderHuligan "Выбран/не выбран" - это событие

Не понял.
Если персонаж выбран — рисуем персонажа в одном виде, если не выбран — рисуем сбоку.
Если у персонажа есть предмет — рисуем в одном виде.
Так что никакое это не событие, это состояние.

Добавлено через 3 минуты

Сообщение от CoderHuligan Причем когда они собраны вместе становится легко оптимизировать код проверок, то есть можно избавится от бесконечных if/else просто обеспечив вызов функций/действий по таблице их указателей в зависимости от входных событий. И вместо лесенок из условий оставить одно.

Что я слышу? Противник ООП говорит про наследование, полиморфизм, интерфейсы?

0

Сообщение от Замабувараев Не понял.

Состояние это - состояние объекта управления, в данном случае - персонажа. События приходят из-вне объекта. А вот в результате этого события объект переходит в состояние конкретного отображения. В данном случае их два 1) рисуем в одном виде (например в анфас) 2) рисуем сбоку.

Сообщение от Замабувараев Если у персонажа есть предмет — рисуем в одном виде.

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

Сообщение от Замабувараев Что я слышу? Противник ООП говорит про наследование, полиморфизм, интерфейсы?

Ну, таблица функций не является прерогативой только ООП концепции.

0

Сообщение от CoderHuligan Прошу отметить, что состояния должны быть взаимоисключающими - в каждый момент времени может быть только одно состояние.

Я не понимаю, как они могут быть взаимоисключающими: мы можем выбрать персонажа, у которого есть в руках предмет.
Функции рисования абсолютно всё равно, что это там за состояния, события, действия. Персонажа нужно нарисовать во всех этих четырёх случаях: выбран без предмета, не выбран без предмета, выбран и в руках есть предмет, выбран и в руках нет предмета.

Добавлено через 1 минуту

Сообщение от CoderHuligan Ну, таблица функций не является прерогативой только ООП концепции.

Таблица функций называется интерфейсом. Интерфейс бесполезен без наследования. Применение нтерфейсов на практике называется полиморфизм.
Вы переизобрели ООП, не пытайтесь отрицать очевидную вещь.

0

Сообщение от Замабувараев А кто‐то считает, что true — это единица.

Их обычно люди, с Паскаля пришедшие, констом задекларивали, мол им глаза резало. Да ещё как-то так:

Намекая что это бул и мол всё логично. Хоть и работало оно как бул, булом не становилось.
Стас мне позже показал про всякие ANDALSO, но я от этого отказался, потому что потребуется портаж
руками - хрен реструктурируешь потом самостоятельно. Сэкономить оно конечно может но
опять же в каких-то местах типа коротких циклов, где основная масса работы ляжет на такие условия
ну и опять же если кодер заранее об этом не побеспокоился и сам не завернул в матрёшку руками.

Сообщение от CoderHuligan "Выбран/не выбран" - это событие. "У персонажа есть предмет" - это булевый параметр.

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

Сообщение от CoderHuligan если нет предмета, то допустим переходим в другое состояние или что-либо делаем (вызываем функцию, которая что-то делает).

Ага а функция ещё кого-нибудь вызывает по GOTO, а там ещё что-то кого-нибудь вызывает и потом оно
по итогу даёт точку выхода куда-нибудь прям в рабочий код, и таких макаронин десятки и сотни, вот тебе и спагетти.
Короче я понял, тебе надо писать такие игрухи где пачка персов\юнитов и их можно выбирать(возможно несколько сразу)
и у каждого свои свойства, такие таски быстро вернут твой мозг в реальность.

Добавлено через 1 час 36 минут

Сообщение от CoderHuligan При обычном программировании мы смешиваем флаги-события, флаги-параметры и флаги-режимы в одно кипучее месиво.. Что за что отвечает с первого взгляда понять невозможно.

Этот подход позволяет написать программу, причём так работает большинство приличных программистов.
Твой же подход позволяет заковыряться и успешно ничего не написать.
В кипучее месиво же превратится мозг, он тупо закипит на стадии прототипирования,
когда ещё не всё ясно мол где какое событие и есть потребность часто видоизменять код.
Даже если предположить идеальные условия для кодинга и хорошего спеца, твой подход
будет работать строго ограниченно и крайне узко в редких алг задачах. При этом видимого
профита в виде скорости может вообще не быть, потому что далеко не весь код пишется
в данной парадигме, часть системного кода уже есть и написана как написана, у драйверов
свой код, остаётся узкая программная реализация(вызов всего того, что уже написано
по другой технологии). То, про что ты говоришь должен в автоматическом режиме на низком уровне
делать компилятор, человек этого месева видеть вообще не должен.

0

Сообщение от Замабувараев Я не понимаю, как они могут быть взаимоисключающими: мы можем выбрать персонажа, у которого есть в руках предмет.

Персонаж не может одновременно сидеть и стоять. По моему все тут ясно. Главное - выделить такие состояния, т.е. режимы.
Наличие предмета в руке - это не состояние, а параметр обьекта (свойство). Обычно такое свойство прописывается в структуре, которая описывает объект.

Сообщение от Замабувараев Функции рисования абсолютно всё равно, что это там за состояния, события, действия.

Функция отображения вообще тут ни причем, это относится к технической части, к util.

Сообщение от Замабувараев Персонажа нужно нарисовать во всех этих четырёх случаях: выбран без предмета, не выбран без предмета, выбран и в руках есть предмет, выбран и в руках нет предмета.

Верно. Но решает это логический блок. У вас логика размазана по всему коду, у меня собрана в одном месте.
Во всех этих случаях персонаж может находится в одном из своих состояний, допустим: идет, сидит, стоит боком и т.п. На вход логического блока поступают события (выбран/не выбран), и в зависимости от них логический блок проверяет параметры, в конкретном состоянии в зависимости от конкретного события. Ну, быстро вспоминаем устройство логических микросхем, где есть входы, логическая часть и выходы. Здесь то же самое.

Сообщение от Quiet Snow Событие это событие, а "Выбран/не выбран" - это свойство, т.е. значение переменной, которое определяет логику(ветвь IF, если выбран - тогда мы например обрабатываем команды персонажу\юниту).

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

Сообщение от Quiet Snow Если персонаж один - можно сделать в коде как ты пишешь, но даже так это хреново, потому что один и тот же код будет дублирован

Почему? Если персонажы однотипны, то и код один и тот же. Да хоть тысяча персонажей - код будет один.

Сообщение от Quiet Snow Если же таких персонажей(или свойств) дофига - твой подход сразу обнуляется, а их обычно и дофига.

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

Сообщение от Quiet Snow Ага а функция ещё кого-нибудь вызывает по GOTO, а там ещё что-то кого-нибудь вызывает и потом оно по итогу даёт точку выхода куда-нибудь прям в рабочий код, и таких макаронин десятки и сотни, вот тебе и спагетти.

За этим обязан следить сам разработчик.

Сообщение от Quiet Snow Этот подход позволяет написать программу, причём так работает большинство приличных программистов.

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

Сообщение от Quiet Snow Даже если предположить идеальные условия для кодинга и хорошего спеца, твой подход будет работать строго ограниченно и крайне узко в редких алг задачах.

Если задача простая, то можно и по старинке, а если со сложным поведением, то нужно применять то, о чем я пишу.

Сообщение от Quiet Snow То, про что ты говоришь должен в автоматическом режиме на низком уровне делать компилятор, человек этого месева видеть вообще не должен.

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

0

Сообщение от CoderHuligan Почему? Если персонажы однотипны, то и код один и тот же.

Чёт не понял, ты состояния хранишь в коде и определяются они по текущей ветви исполнения
или в массивах? Если в массивах - то это классический флаговый подход, о котором я уже расписал.
Флаг это не обязательно бул. Это может ячейка с любым диапазоном значений.

Сообщение от CoderHuligan И вот тут можно вспомнить об ООП, хотя я его и ненавижу лютой ненавистью. Но только применять ограниченное его подмножество, когда часть методов могут обслуживать персонажей разных типов с одинаковыми свойствами. все это можно эмулировать не обращаясь к ООП.

Тогда это уже будет не то, что ты рекламируешь. И когда говорил про "брать лучшее" речь вообще была
не о миксе парадигм. Если удаётся - лучше писать в одной парадигме, в наиболее подходящей под задачу.
То же про что ты говоришь с состояниями - вообще не под задачу, где нужно управлять множеством юнитов.
4GL можно использовать под такие задачи, никто не запрещает, но 99,9% прогеров по части оптимизации
на 4GL в данной задаче дадут страшнейшего петуха, там нужно очень хорошо ориентироваться в слоях
абстракций и в расшаривании памяти, по которой идут пробеги (чтобы не гонять инфу между объектами),
дабы не перебачить лишнего.

Сообщение от CoderHuligan Если задача простая, то можно и по старинке, а если со сложным поведением, то нужно применять то, о чем я пишу.

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

Сообщение от CoderHuligan Почему? Если персонажы однотипны, то и код один и тот же. Да хоть тысяча персонажей - код будет один.

Для этого тебе придётся использовать массив флагов(состояний тех объектов, которыми идёт управление).
Иначе придётся дублирвоать код бесчисленное число раз, на 10 юнитов - 1024 ветви кода, по биту на каждый.
Если хранить выбор нескольких в состояниях кода. На 1000 юнитов считай сам. Оно ни в какую память
компа не влезет, даже будущих поколений компов. Это мягко говоря идиотизм.
Без классических флагов и массивов это не пишется.
Как бы уже определись про что ты нам вещаешь, про состояния в коде или уже про что-то другое.

Сообщение от CoderHuligan Понимание такого кода происходит по диаграммам переходов, а не по листингу кода

Понимание такого кода не происходит даже по диаграммам переходов, нарисованным по листингу руками.
Оно вообще не происходит. 50 макаронин в коде на 300 строк и ты обсираешься как младенец.
А вот по документации(по нормальной, которую писал программист) всё и всегда зашибись.

Сообщение от CoderHuligan Но эта ветвь if должна находится внутри логического блока, вот в чем разница.

Нафига? Какого ещё блока? Сам IF - это и есть логический блок.

Сообщение от CoderHuligan Выбран/не выбран это не состояние объекта, это состояние того, кто управляет этим объектом.

С фига ли? Выбран unit[0, 0] на карте(в спец UDT структуре) (не в стеке или списке, а на карте), а свойство
мол мы берём из Player 1? С чего бы это? Какое отношение свойства Player 1 имеют к свойствам юнита?
Ответ - никакого, это другие свойства другого объекта. При кодинге в 3GL вообще нет необходимости
декларировать игрока как объект, если игроков много создаётся короткий список на основе массива
который потом перебирается в цикле(когда идёт обсчёт каждого игрока, если нам нужно что-то делать
конкретно по каждому, допустим скрипты отрабатывать, уже заранее рассортированные в байт коды).
Да и просто подумай бошкой, у тебя на карте, двухмерной, к примеру несколько тысяч юнитов,
и тебе надо узнать какой юнит под курсором(допустим для всплывающей подсказки). В описанном
тобой случае придётся прошерстить массив на совпадение по координатам чтобы найти юнита, а если их тысячи
то это будет надо делать на каждом кадре и это будет просадка по обсчёту(потому что это лишняя работа
и мы можем её не делать правильно организуя архитектуру и заведя память). Когда мы и без того знаем,
что у каждого юнита куча свойств и их всё равно заводить и сэкономить не получится, почему бы нам
просто не добавить ещё одно свойство "номер игрока" юниту? При том что оно в любом случае потребуется
для огромной кучи кейзов(мы же делаем организацию, исходя из необходимости).

Короче я не представляю как с такой кашей в голове ты вообще что-то можешь писать))). Это жесть.

Добавлено через 10 минут

Сообщение от CoderHuligan Это очень сложно писать, а потом поддерживать свой же код.

Код вообще писать сложно. Особенно обдуманный. А уж если себе барьеры выстроить как
ты сделал - то и вообще невозможно.

Сообщение от CoderHuligan За этим обязан следить сам разработчик.

Ахаха. Ток шоу "уследи за GOTO". Тяжёлое бремя, ничё не скажешь.

Добавлено через 7 минут

Сообщение от CoderHuligan это может быть пользователь, который нажал соответствующую кнопку и выбрал персонажа, но никак не состояние самого персонажа.

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

Добавлено через 14 минут

Сообщение от CoderHuligan Персонаж не может одновременно сидеть и стоять. По моему все тут ясно. Главное - выделить такие состояния, т.е. режимы. Наличие предмета в руке - это не состояние, а параметр обьекта (свойство). Обычно такое свойство прописывается в структуре, которая описывает объект.

То, что юнит делает, т.е. то самое событие(что юнит делает) - это тоже свойство юнита. Так что один хрен.
Смысла разделять - нет, это всё относится к юниту.


Добавлено через 1 час 36 минут
Хулиган, при этом ты так и не написал в каких же сложных задачах флаги-состояния хуже:
а т.е.
- Не справятся (сложность реализации в коде)
- Будут на глаз медленнее(допустим классика - офисники целероны на 2ГГц)
- Будет менее читаемый код (комментированный среднестатистическим программером и читаемый таким же
среднестатистическим)

Пока вот вижу немного другую картину:

- У тебя лёгкий сумбур и ты выдумываешь сущности там, где они не нужны, пример выше,
там всё свойства юнита, но ты придумал "события юнита" и что-то там в коде мутишь под это отдельно.
Зачем? Непонятно. Люди наоборот стараются обычно сгруппировать, унифицировать, создать прослойки.
- Одними лишь "состояниями в коде" не заменить данные, описывающие свойства юнита.
А если ты ими(данными, т.е. массивы\переменные) всё равно пользуешься, то нафига от них отказываться,
выдумывая при этом какую-то свою теорию классификации? Классификация в данном случае не
как кодер захочет, а как задача позволит вообще это сделать.
- Полсотни переходов ложат на лопатки почти любого программиста, сотня - ложит на лопатки
самого автора уверовавшего в непобедимость и неубиваемость своего мозга.
- Код необслуживаем(если код - есть налаженный конвеер, добавление в любое его место какого-либо
функционала сопряжено с трудностями реструктуризации или большим количеством принудительных
"флаговых костылей", которые ты так не любишь, но будешь вынужден добавлять коли функционал попросит,
при этом логика кода становится воистину неотслеживаема, потому как закольцованный не бесконечным
итерационным циклом, а переходами, макаронник - невозможно нормально трассировать из-за отсутствующего
центрального звена, а также стопроцентного начала и конца обработки одного цикла + его фиксированной длины,
приведённый к статике код гораздо более гибок, с ним вообще можно почти всё что угодно творить)

При этом видно, что:
- Т.н. "флаги" в виде: состояний программы, состояний "объектов", свойств UDT структур.
Никак не мешают разбору программы. Более того, позволяют легко вывести эти параметры
при отладке, при этом сразу будет понятно, где допущена ошибка, т.к. состояние флага укажет на
кусок кода, где флаг имеет это состояние. Переходы между состояниями так же легко отлаживать
пробегаясь от самого первого и до последнего.
Флаги прививают итерационное мышление(чуть большее количество операций) нежели прямолинейно
написанный пачкой переходов код или рекурсией, однако отладка и написание такого кода становится
в десятки, а то и сотни раз проще. Т.к. состояния добавляются строго последовательно и по логике алгоритма.

Сообщение от CoderHuligan Это очень сложно писать, а потом поддерживать свой же код.

По поводу поддержки собственного кода. Свои утилиты, по запросу от людей, дописывал спустя 10(!) лет.
В прошлом году ковырял менеджер тайлсетов, который был написан в 2012-м, на разбор проги из больше
косаря строк ушло пара часов времени, думаю не надо объяснять, что прогу забываю спустя неделю, после прекращения
работы над ней.
Это означает, как минимум, что у той идеологии и стиля кода, про который пишу - проблем с этим не выявлено.
Т.е. если ты про это говоришь - то наверное что-то не так делаешь. Стоит задуматься.

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

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

Если этой документации нет - то такой код лично я считаю неподдерживаемым.

0

Много всего понаписали, сразу трудно все осмыслить. Буду помаленьку.

Сообщение от Quiet Snow Чёт не понял, ты состояния хранишь в коде и определяются они по текущей ветви исполнения или в массивах?

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

Сообщение от Quiet Snow Нафига? Какого ещё блока? Сам IF - это и есть логический блок.

При традиционном подходе (ТП).
Имею в виду функцию, в которой собраны все эти наборы if. Функция принимает номер состояния и внутри себя переключается в соответствующий блок, отвечающий за одно состояние объекта. В этом блоке собраны воедино все эти if.

Сообщение от Quiet Snow Полсотни переходов ложат на лопатки почти любого программиста

А полсотни флагов нет, что ли? У вас на каждый чих идут спаренные проверки, типа:
если (флаг_сидит И держит_пистолет) бла-бла;
если (флаг_сидит И держит свой_чл.н) еще одно бла-бла.
И так далее. Это нормально?
У меня же это обрабатывается в состоянии "сидит":
если (держит пистолет) бла-бла;
если (держит_свой_чл.н) еще одно бла-бла;
И что имеем? Куда-то делись логические проверки на "И" и сам флаг сидит..
Ок?

Сообщение от Quiet Snow Т.н. "флаги" в виде: состояний программы, состояний "объектов", свойств UDT структур. Никак не мешают разбору программы.

Эти флаги надо все помнить, а это большая нагрузка на мозг. И еще по поводу подходов. Возьмем простой пример. Откроем википедию "пузырьковая сортировка"- https://ru.wikipedia.org/wiki/... 0%BE%D0%BC. Там пиведен код на бейсике улучшенного варианта пузырьковой сортировки:
Я его переписал на Си и сделал свой вариант.
Посмотрите на этот код. Совершенно очевидно, что флаг F когда получает значение 1 продолжает его получать и далее, если есть обмены. Но достаточно присвоить 1 всего один раз. Налицо непризводительное использование процессорного времени, а в итоге и времени пользователя, потому что из таких вот мелочей это время все время утекает, становится больше. Так большинство привыкло программировать, так учат в вузах. Но все это не верно! Правильный код я приведу ниже. Сначала переписанный на си:
Правильный код от CoderHuligan:
Я хочу, чтобы вы помедитировали над ним, так как он многое вам прояснит из моего подхода. Он также учитывает, что часть массива или весь массив может быть отсортирован. Но при этом не имеет флага, он куда то испарился. Так же куда-то испарилось бесполезно растрачиваемое время процессора, которое он тратил в первом варианте на присваивание значения 1 переменной f.
Пока все.

Добавлено через 37 минут
Уточненный код, который учитывает внутренние проходы:

1

Сообщение от CoderHuligan Я хочу, чтобы вы помедитировали над ним, так как он многое вам прояснит из моего подхода.

Если был всего лишь один обмен, ваш «правильный» код будет бегать по массиву N-1 раз помноженное на N-j-1. То есть сложность как была квадратичная, так и остаётся если перепутаны только два соседних элемента.

В сортировке с флагом такого не происходит: если после обмена массив превратился в отсортированный, то это обнаружится на следующей итерации, произойдёт выход из цикла, и прохода по массиву оставшихся N-j-1 не будет.

Добавлено через 15 минут

Сообщение от CoderHuligan Так же куда-то испарилось бесполезно растрачиваемое время процессора, которое он тратил в первом варианте на присваивание значения 1 переменной f.

Очень интересно, а вы сравнивали размеры инструкций jmp (в которую превращается GOTO) и размер инструкции xor для какого‐нибудь регистра (в которую превращается f = 1)? И нарушает ли прыжок предсказатель переходов процессора, если нарушает, насколько он замедляется по сравнению с такой простой операцией как xor eax, eax?

0

Сообщение от CoderHuligan Уточненный код, который учитывает внутренние проходы:

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

Если взглянуть на код на Бейсике, то все очень хорошо читается

0

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

Сообщение от Замабувараев Очень интересно, а вы сравнивали размеры инструкций jmp (в которую превращается GOTO) и размер инструкции xor для какого‐нибудь регистра (в которую превращается f = 1)?

Если большая часть массива будет отсортированной, выигрыш будет значительным. Можно сделать бенчмарк. Потом может сделаю.

Сообщение от m-ch Понять, как работает данный код невозможно.

Его понимают не по листингу, а по диаграммам переходов как в uml.

1

Сообщение от CoderHuligan Эти флаги надо все помнить, а это большая нагрузка на мозг.

Что за бред? Зачем их помнить? Они не должны быть все взаимосвязаны. Кодер держит в голове только те
состояния, с которыми работает в текущий момент. Т.е. задекларировал, даже если что-то забыл - вернулся
к декларациям и вспомнил. Их сотни могут быть, все не запомнить. Это вовсе не предполагается.

Сообщение от CoderHuligan Я хочу, чтобы вы помедитировали над ним

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

Сообщение от CoderHuligan А полсотни флагов нет, что ли? У вас на каждый чих идут спаренные проверки, типа: если (флаг_сидит И держит_пистолет) бла-бла; если (флаг_сидит И держит свой_чл.н) еще одно бла-бла. И так далее. Это нормально?

Отвечаю. Во время прототипирования - абсолютно нормально. Во время релиза - эта дикая срань должна
быть уже формализована и все взаимосвязанные состояния должны быть сгруппированы. Т.е. утрированно
Но вообще это всё сильно непредметно и один хрен что мы тут дискутируем. Более того ты перешёл от обсуждения
больших и крупных прог опять на 10-ти строчное говно и пытаешься доказать что твой подход рулит.
Я и не спорил, что он рулит на 10-ти строчном говне. Так что пока не напишешь что то крупнее - не осознаешь,
что флаги это мало того что удобно, так ещё и необходимость, они как раз очень строго структурируют
состояния и их последовательности. И не всегда удаётся обойтись лишь флагами и пачкой состояний.
Бывают и спаренные проверки, бывает что по другому просто никак, ну т.е. совсем никак и как не извивайся
хрен напишешь по другому. Так что ты тут сильно не прав в плане что вот есть твоя единственная идеология
и с ней всё будет зашибись. Более того ты её и сформулировать не можешь, то у тебя объекты, то состояния в коде,
то ты уже флаги приписываешь к "состояниям в коде".

Сообщение от CoderHuligan В структуре объекта. За это отвечает единственная переменная. Если объектов несколько, то определяется массив объектов.

Сообщение от CoderHuligan Функция принимает номер состояния и внутри себя переключается в соответствующий блок, отвечающий за одно состояние объекта. В этом блоке собраны воедино все эти if.

Какой в жопу объект? Я не говорю про ООП. Пишу на 3GL, при нехватке оптимизации критические участки пишу на 2GL.
У меня нет инкапсуляции, потому что 3GL, обхожусь без этого, легко и нормально обхожусь, она нужна для 4GL,
если ты в нём пишешь и ему следуешь и то тебя там закритикуют нахер любители передавать из одного
объекта в другой, люди, которые и ассемблера то не нюхали.
А то, что ты описал это процедура с SELECT CASE внутри. Это классический флаговый подход,
потому что на вход кейза приходит переменная флаг. И озвученная привязка: входная переменная из параметра
процедуры к переменной непосредственно в SELECT CASE имеет нулевой смысл, ты просто выдумал какую-то
организацию и искусственно ограничил себя процедурой с одним кейзом, а нормально объяснить зачем ты
это делаешь - не можешь. Нахрена это делать - не ясно.
И это точно не состояния в коде, про которые ты говорил раньше, а какая-то невообразимая дичь, смысл которой
не осязаем.

Добавлено через 7 минут
И кодер любую спарреную логику не факт что тебе удастся упростить в принципе.
В этом деле есть более понятные и простые решения и более хитро закрученные через
хитро закрученную жопу, которые чуточку быстрее работают, но их код ужасен и взывает
трепет, страх, а порой и ужас. Но есть вовсе бестолковые, которые усугубят кодинг до
того что прогер сам запутается в своём художестве, сломает колено, прострелит ногу,
причём дважды, упадёт выбив зубы, а упавший на голову шотган вдобавок прострелит бошку.
Так вот мне кажется что твой подход ближе к последнему.

0

Ты вот всё изобретаешь изобретаешь, а нифига изобретать не надо, тебе уже рассказывали и показывали
как надо делать. Но нет тебе так неудобно, плохо и т.п. ну так дело в тебе, а не в идеологии.
Ну изобретай дальше. Может когда-нибудь чего и изобретёшь, когда даже у пацанов тех, кто
сильно младше тебя будет уже по 10 приличных проектов, честно написанных.
Просто именно тогда осознание придёт, а голова уже сточена будет в мясо. Прогай, пока есть бошка,
пока ты куропаткой не стал рассеянной, потом поздно будет.

0

Сообщение от Quiet Snow Может когда-нибудь чего и изобретёшь, когда даже у пацанов тех, кто сильно младше тебя будет уже по 10 приличных проектов, честно написанных.

Я не работаю на компанию. "Приличных" - понятие растяжимое.. У меня проект в разработке. Но опять же это не ради денег.
По поводу изобретаешь. Это в крови. Но это сейчас никому не нужно. хотя: может было бы нужно если бы это можно было бы потрогать. Например ЯП с русским синтаксисом типа Рапиры. Кумир - отстой. До сих пор этого ничего нет. Поэтому изучаю создание компиляторов. В принципе уже знаю как это можно реализовать. То есть у каждого свои заморочки.

Сообщение от Quiet Snow Какой в жопу объект? Я не говорю про ООП.

Я тоже. Объектом я называю структуру, которая описывает какую либо сущность, типа персонажа. Это объект управления. То что им управляет есть автомат.

Сообщение от Quiet Snow А то, что ты описал это процедура с SELECT CASE внутри. Это классический флаговый подход,

Если этот case поместить внутрь цикла, то это и будет логическим блоком. Потому что иначе вы не можете прейти из состояния "сидит" в "стоит" внутри самого case.

Сообщение от Quiet Snow Нафига мне этот бабл и твои проги на 10 строк? Использую кастомную двустороннюю сортировку вставками вкупе с рапидом. На мои задачи пока хватает. И на кой хрен мне твой код на си? Я на нём не пишу.

Дело не в конкретной сортировке и не в языке. А в том, как вместо флагов и структурной парадигмы можно испоьльзовать другой подход, который:
1. позволяет иногда убыстрить код
2) повысить понимание кода, так как в нем все на своем месте и описывается документом.
3) автоматически верифицировать код пр помощи математики, которая описывает конечные автоматы.

0

Сообщение от CoderHuligan 1. позволяет иногда убыстрить код

Нет, не позволяет. Прыжки нарушают работу предсказателя команд процессора, на это тратятся дополнительные такты.

Сообщение от CoderHuligan 3) автоматически верифицировать код пр помощи математики, которая описывает конечные автоматы.

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

0

Сообщение от CoderHuligan Так же куда-то испарилось бесполезно растрачиваемое время процессора, которое он тратил в первом варианте на присваивание значения 1 переменной f.

Зато выросло куча GOTO, прыгающее внутрь циклов и обратно. Можно представить
что там будет в худшем случае. Т.е. ты улучшаешь алгоритм, ухудшаешь реализацию,
делаешь код абсолютно нечитаемым и запутанным и выдаёшь это взаправду.

Сообщение от CoderHuligan 2) повысить понимание кода, так как в нем все на своем месте и описывается документом.

А сам то ты этому следуешь?

Сообщение от CoderHuligan Потому что иначе вы не можете прейти из состояния "сидит" в "стоит" внутри самого case.

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



Добавлено через 15 минут

Сообщение от CoderHuligan "Приличных" - понятие растяжимое.

Говорить говори, но не заговаривайся. Приличных это понятие очень даже понятное и осязаемое.
Вот например уЗамабувараев-а приличный проект, действительно хрен такой напишешь,
а вот твой морской бой - это вообще не проект, а детская забавка. У locm-a был тоже приличный проект,
тоже уровня хрен напишешь. У меня были приличные проекты, тоже уровня хрен напишешь,
например софтвар рендеры на бейсике и паскале с текстурами на ассемблере написанные руками,
а не транслятором. Или редактор карт, я его только собирал из готовых(!) API три с хреном недели,
сами же API разрабатывались 2,5 года, это не просто с хрену сел и накодил за пару месяцев.

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

Добавлено через 21 минуту

Сообщение от CoderHuligan 3) автоматически верифицировать код пр помощи математики, которая описывает конечные автоматы.

Правильно написаный код НЕ нуждается в какой-то там верификации.
Если аналитически всё расшиблено до атомов и сделана полная формализация механизмов.

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

Добавлено через 39 минут

Сообщение от CoderHuligan Его понимают не по листингу, а по диаграммам переходов как в uml.

Схемами\блоками\стрелочками на листе бумаге мы пользовались задолго до того, как об UML вообще начали лопотать.
А даты эти люди могли поставить в википедиии любые, её правит любой болван. Ты можешь приколоться, изобрести
что-нибудь, например свой ЯП и написать что ты его создал ещё до даты своего рождения, кретины поверят))).
Мы помним как быстро "мир"(а т.е. запад) переписал историю и какое описание поколений ЯП в книгах было раньше
и какое на профильных сайтах лежит сейчас.

Сообщение от CoderHuligan хотя: может было бы нужно если бы это можно было бы потрогать. Например ЯП с русским синтаксисом

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

0

Сообщение от Quiet Snow Зато выросло куча GOTO, прыгающее внутрь циклов и обратно. Можно представить что там будет в худшем случае. Т.е. ты улучшаешь алгоритм, ухудшаешь реализацию, делаешь код абсолютно нечитаемым

Объясню. Частично вы правы. Но только потому, что это не чистый код на goto, а жуткая смесь структурного и неструктурного кода. Вот почему он выглядит довольно странным даже для меня, хотя он алгоритмически верен. То есть дело-то не в способе, а в самом алгоритме. его можно переписать по другому и это будет более понятным и ясным. Я пошел на это, только из-за желания уменьшить количество goto.

Сообщение от Quiet Snow А сам то ты этому следуешь?

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

Сообщение от Quiet Snow Но так, к слову, вообще-то, могу

Дык это понятно, что на goto можно. А без goto как? Только так:

Сообщение от Quiet Snow а вот твой морской бой - это вообще не проект, а детская забавка.

Не сказал бы что детская. Конечно по сравнению с большими прогами - да, детская, но большая часть алгоритмов там интересных, совершенно самостоятельных.

Сообщение от Quiet Snow API три с хреном недели, сами же API разрабатывались 2,5 года, это не просто с хрену сел и накодил за пару месяцев.

Но если нет вменяемого описания, то никто не будет тратить 2,5 года на разбор этого кода.
То есть: чтобы код жил, нужно потратиться на доки.

Сообщение от Quiet Snow Правильно написаный код НЕ нуждается в какой-то там верификации.

Зачем тогда придумали различные анализаторы для статического анализа кода? Типа PVS-Studio и др. Они отлавливают множество ошибок в существующих проектах, даже в коде линукс и пр. Основная проблема не в анализе на элементарные ошибки - в анализе самих алгоритмов и вот тут нужно привлекать мат-аппарат заточенный на автоматную теорию. А как их применять если большинство пишет в отрыве от оной?
Вот и будут продолжать падать боинги и разбиваться автомобили.

Сообщение от Quiet Snow Схемами\блоками\стрелочками на листе бумаге мы пользовались задолго до того, как об UML вообще начали лопотать.

Где кружки - это состояния, а где стрелочки - переходы. И все становится понятным из-за сжатого в объеме самого существа алгоритма. Это просто сделать.

Сообщение от Quiet Snow Это всё философия. Русский ЯП это будет хорошо, но не для тебя.

Но кто-то же должен начать? Мы ж курс на импортозамещение взяли. А где наши языки?

Добавлено через 1 минуту

Сообщение от Замабувараев Прыжки нарушают работу предсказателя команд процессора, на это тратятся дополнительные такты.

О чем вообще? В ассемблерном коде после циклов тоже прыжки остаются.

Сообщение от Замабувараев Чтобы сработала математика, мы должны иметь чистые функции без побочных эффектов.

Какие чистые функции? Чистые функции не предполагают наличие состояний, а значит не могут быть верифицируемы в принципе.

0