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

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

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

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

Начало тут

0

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

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

0

Сообщение от CoderHuligan Зачем тогда придумали различные анализаторы для статического анализа кода?

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

Сообщение от CoderHuligan Основная проблема не в анализе на элементарные ошибки - в анализе самих алгоритмов

AI ещё не научили писать алгоритмы, это я к тому что проверка как-бы тоже пока невозможна.
Анализаторы проверяют по шаблонам на банальные ошибки к алгоритмам это не относится.

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

Было же сказано что этот код непредметный, тут нечего обсуждать. Таких штук в реале нет.
А ждать пока луп прокрутится - это вообще бред, флаги применяются там, где они не дадут слоудаун
из-за лишних пары холостых прокруток цикла и это офигенно малая цена за раскладку алгоритма
в линейный итеративный вид, где можно по одной итерации блоху под микроскопом ковать.
И состояния там всегда строго разделены, нет никакой даже малейшей необходимости прыгать из
одного в другое, потому что сам алг разложен в итеративный несвязанный по состояниям вид.
Если ты опускаешься до сортировок и до переходов, то это означает, что лично тебе в твоём коде
требуется критическая оптимизация, это в свою очередь означает что надо спуститься на уровень
ниже на ассемблер и там уже оптимизировать. Есть простая закономерность: чем качественнее
твой алгоритм, тем меньше эффект от технической оптимизации. В идеальном случае это
85%-95% и соотв 15%-5%. По большому счёту достаточно просто хреначить нормально алгоритмически
чтобы уже хорошо работало просто не все это умеют и с должным качеством, Antony Gual
это доказывал и рейкастером и Jpeg декодером. Когда ты размазываешь оптимизацию по всей программе
а не усираешься в отдельно взятой сортировке - общий эффект от твоей оптимизации гораздо выше
и заметнее, при этом упор на алгоритмич. оптимизацию даёт максимальный эффект. Про это уже
рассказывал когда расписывал потребность всё писать руками и пояснял, что даже если что-то не
дотягивает до эталонных рыночных образцов - беды в этом нет, коли всё формализуется и идёт работа
над алгоритмами, потому что софт именно в среднем будет иметь возможность работать быстрее аналогов,
конечно это зависит от приложенных усилий и самого программиста, но описываемый мною подход даёт
такие возможности. Тайн никаких нет, это вполне себе понятная и логичная стратегия разработки.

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

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

Сообщение от CoderHuligan Не сказал бы что детская.

Уже толковал, что твоя задача для практического программиста это два-три месяца работы,
когда есть рабочее место, настроенная IDE и никто не мешает. Уразумей это.
Там есть интересные и сложные моменты, но грубо говоря ты делаешь прогу чисто для себя(бестолковость++).
А если делать на коммерс, то там упарываться не надо, это озвученный срок + оформление всего этого дела
и ты должен был это понять в холиварах, которые на тему твоей игры вспыхивали.
В моих реализованных задачах ты бы утонул на долгие годы и не факт что скодил, я и сам там кое-где обосрался
много на себя взяв, надо порой понимать что на свои плечи взваливаешь соизмеряя с уровнем подготовки,
опыта и личного кодархива.

1

Сообщение от Замабувараев Верифицировать можно только такую функцию, которая зависит только от своих параметров, и не зависит от состояний.

Функция это черный ящик, у которого есть вход и выход. Выход зависит от состояния самой функции. Поэтому верификация это не тестирование.

0

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

Курс на импортозамещение похоже дал петуха. Вместо полноценных 8-16 ядерных Эльбрусов
людям впаривают аналоги мобильных ЦП на дешёвом говняном текстолите за деньги, на которые
можно было бы собрать жирного монстра из Китая или середняка из регионалки.
Осеписателей нет, т.е. совсем и порты линукса - это всё что данное железо ожидает.
Спецификации - закрыты, эмулятор - закрыт. Видеоядра, очевидно, чужие. Элементная база - Китай.
А лазер на 130Нм будет готов к 2025-му году. Короче к ребятам вопросов много.
Жаренный петух их как-то слабо уклюнул, пока что-то глобальное не случится - так и будут хрен пинать.

0

Сообщение от Quiet Snow Вот это и есть целевой контингент этих анализаторов.

Но кто-то же должен разгребать их .овнокод. Пусть этим занимаются анализаторы. Кстати очень занимательное чтиво: посмотрите на хабре статьи по PVS-Studio. Хотя продукт и не бесплатен, но интересны примеры руко.опости, которые он вскрывает.

Сообщение от Quiet Snow А ждать пока луп прокрутится - это вообще бред, флаги применяются там, где они не дадут слоудаун из-за лишних пары холостых прокруток цикла

Нормальный оптимизирующий компилятор превратит switch в массив указателей на метки.

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

Как это? Наоборот: все состояния четко разделены, что и требуется. То есть вся работа в отдельных состояниях собрана в одном месте - в отдельном casе. За все возможные состояния отвечает единственная переменная.

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

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

0

Сообщение от CoderHuligan А как этот кодер будет искать все условия в коде, если эти условия размазаны по всему коду?

Кодер, уже писал, что ты логику не упростишь больше чем это возможно. Сортировку делать флагами
- это дебилизм, а вот прогу которую я выше приводил - ты без флагов не напишешь вовсе хоть ты конём епись))).
Как, как... По комментариям и документации. Ты думаешь у тебя кода меньше будет на одну и ту же задачу?
И мол нагрузка на голову меньше, да ты наивняк пипец. Ищещь золотой грааль, которого нет.
У тебя есть алгоритм, который работает отталкиваясь от состояний, состояния сгруппированы в CASE,
внтури кейза необходимые условия или ещё кейзы или цикл или формулы или вызовы процедур\функций,
каждое состояние делает свою часть работы и переключается(переменная в кейзе меняет значение).
Таких переключений может быть много. И если GOTO ты можешь не группировать и прыгать
хер знает куда(а лохи или ещё большие извращенцы так и будут делать) то CASE сидит ровно в одном месте,
найти в нём состояние не проблема, более того он и заточен под это, он буквально орёт тебе - "вот тут состояния
элементов алгоритма". Они отрабатывают последовательно, состояние(участок кода) не завершившее свою работу
не прыгает по 10 раз туда сюда - потому что это говнокод. В самых общих случаях алгоритм строится так, что состояния
идут друг за другом, на то в какое русло переключится состояние может влиять бесчисленное кол-во факторов.
И как бы там ни было зашиты эти состояния будут в порядке того как разрабатывался алгоритм, если при разработке
человек всё разложил по полочкам - то будет очень даже читабельно, т.к. одного взгляда будет достаточно,
чтобы понять что это последовательно идущие части одного толстого алгоритма, разбитого на состояния.
И опять же не все алгоритмы удастся нормально сделать на флагах, но их множество гораздо более обширное, чем
всех остальных. Они дофига где применяются, например, в большинстве конвеерных задач.

0

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

Вы описываете грязную функцию.
Чистая же функция при одних и тех же параметрах всегда будет выдавать один и тот же результат.

0