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

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

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

Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ (не дополнительной документации или комментариев!), и/или устранения проблемы "блуждания среди деревьев" без радикального ущерба для других свойств языка программирования? Интересуют так же мнения вообще о том, как повышать читаемость программ и/или методики изучения больших программ, улучшающие усвоение информации.

Здравствуйте, 0x7be, Вы писали:

0>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ

Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.

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

Здравствуйте, VladD2, Вы писали:

0>>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ
VD>Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.

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

Здравствуйте, vayerx, Вы писали:

V>Здравствуйте, VladD2, Вы писали:

0>>>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ
VD>>Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.

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

Нет. Есть не верное видение проблемы. Проблема не в способах. Главная проблема в людях, а выбор средств и методов уже зависит от них.

Здравствуйте, 0x7be, Вы писали:

0>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ (не дополнительной документации или комментариев!), и/или устранения проблемы "блуждания среди деревьев" без радикального ущерба для других свойств языка программирования? Интересуют так же мнения вообще о том, как повышать читаемость программ и/или методики изучения больших программ, улучшающие усвоение информации.

Декларация — наше всё.

Здравствуйте, VladD2, Вы писали:

VD>Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.

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

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

[offtop]
Когда же в немерле будет стандартная библиотека с этими "эвристиками", для решения широкого круга задач?
[/offtop]

Здравствуйте, fin_81, Вы писали:

_>То есть ты утверждаешь, что задачу комивояжера, выполнимости булевых формул и тп можно решить за полиноминальное время, поменяв лишь мозги программистам и архитекторам?

Конечно! Речь же идет о решении (т.е. создание программы), а не времени затрачиваемом на вычисления. В прочем последнее тоже зависит от того кто решает задачу.

_>Похожие задачи постоянно приходится решать во время написания, чтения, понимания кода.

Да ладно! Постоянно? У тебя очень интересная практика .

_>В общем случае сложность как была экспоненциальной, так и осталась. Только в конкретной специализации можно использовать всякие эвристики для ускорения поиска, для ухода от экспоненциальной сложности.

Ты в следующий раз прежде чем влезать в разговор и лепить глупости невпопад потрать 10 минут на внимательное изучение темы обсуждения. Здесь не обсуждается проблемы вычислительной сложности. Здесь обсуждается вопрос создания, развития и поддержки кода проектов.

_>[offtop]
_>Когда же в немерле будет стандартная библиотека с этими "эвристиками", для решения широкого круга задач?
_>[/offtop]

Мозг Немерл не заменит. Так что тем у кого его нет ловить в Немерле нечего. В прочем как и в программирвоании в целом.

Здравствуйте, VladD2, Вы писали:

VD>Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.
Безусловно это повышение читаемости.
Но я не вижу как это поможет придать программам линейности изложения. Все равно элемент "блуждания по лесу" остается, просто деревья толще и их меньше.

VD>Проблема только в том, что сложность решаемой задачи, отсутствие времени, примитивность инструментов и неумелые действия программиста/архитектора рано или поздно приводят большинство проектов с ужасное состояние.
Увы, это так. Впрочем, мне сейчас повезло работать в проекте, где качеству кода уделяется много внимания и существенные силы вкладываются в maintainability кода, в т.ч. и в его читаемость. Однако проблема читаемости остается.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, fin_81, Вы писали:

_>>То есть ты утверждаешь, что задачу комивояжера, выполнимости булевых формул и тп можно решить за полиноминальное время, поменяв лишь мозги программистам и архитекторам?

VD>Конечно! Речь же идет о решении (т.е. создание программы), а не времени затрачиваемом на вычисления. В прочем последнее тоже зависит от того кто решает задачу.

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

_>>Похожие задачи постоянно приходится решать во время написания, чтения, понимания кода.
VD>Да ладно! Постоянно? У тебя очень интересная практика .
По другому не получается работать, постоянно приходится искать/помнить что же задумал мой коллега, писатель библиотек, или сам месяц назад. И на основе этого писать что то новое. Хорошо что задачи узкоспециализированы, есть определенные эвристики для сокращения сложности. Но иногда приходится переключаться на другие задачи, приходится войти в курс дела, придумывать, искать новые эвристики (похоже на поиск кратчайшего пути и логический вывод). Хорошо если задача знакомая, и отложилась в моей неэкспоненциальной памяти. Отсюда делаю вывод что в общем случае нет "серебряной пули". И всякие абстрагирования, декларативность, замена программистов предназначены для решения определенных и конкретных проблем с моделированием, способом решения и HR.

_>>В общем случае сложность как была экспоненциальной, так и осталась. Только в конкретной специализации можно использовать всякие эвристики для ускорения поиска, для ухода от экспоненциальной сложности.
VD>Ты в следующий раз прежде чем влезать в разговор и лепить глупости невпопад потрать 10 минут на внимательное изучение темы обсуждения. Здесь не обсуждается проблемы вычислительной сложности. Здесь обсуждается вопрос создания, развития и поддержки кода проектов.
Ну извиняюсь за свою безграмотность, но я здесь увидел проблему с эквивалентностью N и NP полных задач. В общем случае задачи — NP-полные, при решении которых мы упремся в ограничения в памяти, включая память для кода программы, или во времени. Пытаясь обойти эти ограничения мы вводим свои ограничения, придумываем эвристики и решаем уже другую задачу, похожую на первоначальную, хорошо если задача N-полная.
Я хочу сказать, в общем случае абстрагирование, декларативное программирование, замена мозгов у программистов находит только часть корней NP-полной задачи. Что делать если нам нужны все решения, или те решения которые не нашла наша программа.
Линейный текст, абстрагирование, живописное описание в художественной литературе не способно описать все характеристики реального предмета.

[offtop]
Не надо решать общие, глобальные задачи. Надо решать конкретные задачи. А если, вдруг, ваше решение находит решения другой задачи, то это супер. Но не надо рекламировать ваш способ решения для решения всех задач, скорее всего он не находит все нужные решения.
Абстрагируйте то что абстрагируется, декларируйте то что декларируется, меняйте мозги тем, чьи мозги можно менять.
[/offtop]

Здравствуйте, fin_81, Вы писали:

_>Мне например сложно экспоненциально не напрягая свой мозг быстро найти правило в ПегМакросах которое сработает для данной строчки кода.

Ну, что я тебе могу сказать к тому что уже сказано? Мозг — это одна из составляющих. Причем самая важна. Так что наваливайся на его развитие.

_>Или приходится держать все правила с откатами в мозгу, или сидеть с бумажкой и проверять каждый макрос. То есть я должен быть экпоненциально умен или экпоненциально быстро писать.

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

В любом случае иметь дело с грамматикой намного проще нежели иметь дело с кодом реализующим ее. Вот чтобы понять его (пни некоторых объемах) может не хватить и самой умной головы.

_>>>Похожие задачи постоянно приходится решать во время написания, чтения, понимания кода.
VD>>Да ладно! Постоянно? У тебя очень интересная практика .
_>По другому не получается работать, постоянно приходится искать/помнить что же задумал мой коллега, писатель библиотек, или сам месяц назад.

Может дело в том, что вы забываете документировать код? Или все же в том, что вы пользуетесь дремучими и не эффективными средствами и методами разработки и в результате получаете гору говнокода вместо того чтобы иметь дело с декларативными решениями?

_> И на основе этого писать что то новое. Хорошо что задачи узкоспециализированы, есть определенные эвристики для сокращения сложности.

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

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

Сочувствую. Переключение — это всегда тяжелая и не продуктивная нагрузка.

_>Хорошо если задача знакомая, и отложилась в моей неэкспоненциальной памяти. Отсюда делаю вывод что в общем случае нет "серебряной пули". И...

...надо месить говнокод не утруждая себя какими-то мудреными изысками.

Это ты имел в виду?

_> всякие абстрагирования, декларативность, замена программистов предназначены для решения определенных и конкретных проблем с моделированием, способом решения и HR.

Сам то понял что написал? Я не осилил.

_>Ну извиняюсь за свою безграмотность, но я здесь увидел проблему с эквивалентностью N и NP полных задач.

Где же ты ее тут разглядел? Эти проблемы проистекают из идеи решения задач с большим объемом вариантов (данных) путем тупого перебора. Создание же ПО — это всегда создание весьма ограниченного объема кода.

_>[offtop]
_>Не надо решать общие, глобальные задачи. Надо решать конкретные задачи. А если, вдруг, ваше решение находит решения другой задачи, то это супер. Но не надо рекламировать ваш способ решения для решения всех задач, скорее всего он не находит все нужные решения.
_>Абстрагируйте то что абстрагируется, декларируйте то что декларируется, меняйте мозги тем, чьи мозги можно менять.
_>[/offtop]

Спасибо за консультацию Кэп!

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, fin_81, Вы писали:
_>>Мне например сложно экспоненциально не напрягая свой мозг быстро найти правило в ПегМакросах которое сработает для данной строчки кода.
VD>Ну, что я тебе могу сказать к тому что уже сказано? Мозг — это одна из составляющих. Причем самая важна. Так что наваливайся на его развитие.
То есть плевать на сложность понимания правил, если не понятно то виноват программист, так как он не смог осилить 100500 правил. Развивай мозг чтобы все эти правила влезли и чтоб ты смог все откаты вместить в свой мозг, иначе ты плохой программист. Что это не вяжется с темой про читаемость и понятность.

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

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

VD>Сочувствую. Переключение — это всегда тяжелая и не продуктивная нагрузка.
Вот пишешь-пишешь UI для редактора словаря, а потом бац, пиши работу с tcp протоколом. И все это в пределах одной задачи. Какие абстракции посоветуешь, языки? Чтоб сразу с лету в течении одного рабочего дня вникнуть и начать работу. И чтоб мой код я сам через месяц не выкинул на помойку, и коллеги UIщики понимали?

Здравствуйте, 0x7be, Вы писали:

...
0>Большой засадой на пути понимания кода является то, что в отличие от большинства естественных текстов, программа не является линейным текстом. У программ нет вступления, сжатого тезисного изложения основных идей, линии повествования и постепенного раскрытия замысла автора. Программы — это клубки связанных понятий, которые ещё и не понятно с какой стороны разматывать. В них не всегда можно быстро выделить ключевые абстракции, уточняющие абстракции, главные пути исполнения и т.п.
...
0>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ (не дополнительной документации или комментариев!), и/или устранения проблемы "блуждания среди деревьев" без радикального ущерба для других свойств языка программирования? Интересуют так же мнения вообще о том, как повышать читаемость программ и/или методики изучения больших программ, улучшающие усвоение информации.

1) Генетический способ изложения — почему этот оператор тут появился? Что было раньше? Какие есть альтернативы .
2) Переход в 3Д, но не UML — нужно удобнее.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, vayerx, Вы писали:

V>>Здравствуйте, VladD2, Вы писали:

0>>>>Собственно, вопрос — как думаете, есть ли способы радикально повысить читаемость кода программ
VD>>>Конечно ест. И всех их знаю. Это декларативность, абстрагирование и модульность.

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

VD>Нет. Есть не верное видение проблемы. Проблема не в способах. Главная проблема в людях, а выбор средств и методов уже зависит от них.

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

А по делу, я предпочитаю писать так:

foo = mainIdea ofFunction where
  -- основная идея функции в терминах предметной области
  mainIdea = doSomething `andThen` doSomethingElse
  ofFunction = forExampleCheckAguments
  -- определения подфункций
  doSomething = parseUsingRule rule1
  doSomethingElse r = logResults r
  forExampleCheckArguments = throwOnFail [
    (arg > 10, "Arg must be greater than 10"),
    (arg /= 0, "blablabla")]
  -- детали
  andThen f g = f >>= g
  throwOnFail lst = when (not (and (map fst lst))) $ throwError "booooom"

Сама возможность сначала писать использование, а потом определения, позволяет первым делом писать самое важное, однако не стимулирует так делать, поэтому написать ерунду тоже можно. Как это сказывается на коде в целом, не могу сказать.
Лично мне возможность писать foo bar baz where ... очень нравится. Must have.

Здравствуйте, VoidEx, Вы писали:

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

Язык не более чем средство. Он может способствовать или препятствовать получению качественного кода. Но конечный результата по любому зависит от людей. Дай в руки "обезьяны" самый крутой язык и все равно код будет превращен в кашу. Возможности абстрагирования просто не будут задействованы.

VE>Так что будь проблема и в людях, в глобальном масштабе их не поменять, в отличие от языков.

Один лишь язык проблемы не решит.

VE>А по делу, я предпочитаю писать так:
VE>

VE>foo = mainIdea ofFunction where
VE>  -- основная идея функции в терминах предметной области
VE>  mainIdea = doSomething `andThen` doSomethingElse
VE>...
VE>

VE>Сама возможность сначала писать использование, а потом определения, позволяет первым делом писать самое важное, однако не стимулирует так делать, поэтому написать ерунду тоже можно. Как это сказывается на коде в целом, не могу сказать.

Ну, и зря. Лично я предпочитаю кишки реализации убирать по дальше, а не в тело функции. В прикладном коде должна быть только прикладная логика, причем, выраженная в максимально близком виде к декларации задачи. А кишки реализации лучше держать совсем в другом месте.

VE>Лично мне возможность писать foo bar baz where ... очень нравится. Must have.

Может это и не плохо, но проблемы это не решит ни в каком виде.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, VoidEx, Вы писали:

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

VD>Язык не более чем средство. Он может способствовать или препятствовать получению качественного кода. Но конечный результата по любому зависит от людей. Дай в руки "обезьяны" самый крутой язык и все равно код будет превращен в кашу. Возможности абстрагирования просто не будут задействованы.

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

VE>>Так что будь проблема и в людях, в глобальном масштабе их не поменять, в отличие от языков.

VD>Один лишь язык проблемы не решит.

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

VE>>А по делу, я предпочитаю писать так:
VE>>

VE>>foo = mainIdea ofFunction where
VE>>  -- основная идея функции в терминах предметной области
VE>>  mainIdea = doSomething `andThen` doSomethingElse
VE>>...
VE>>

VE>>Сама возможность сначала писать использование, а потом определения, позволяет первым делом писать самое важное, однако не стимулирует так делать, поэтому написать ерунду тоже можно. Как это сказывается на коде в целом, не могу сказать.

VD>Ну, и зря. Лично я предпочитаю кишки реализации убирать по дальше, а не в тело функции. В прикладном коде должна быть только прикладная логика, причем, выраженная в максимально близком виде к декларации задачи. А кишки реализации лучше держать совсем в другом месте.

Тут лишь локальные по отношению к функции кишки. Более общие кишки выносятся в самый конец модуля и не экспортируются. Идея в другом, в определении функции первым делом идёт суть функции, которая постепенно раскрывается, а не десяток определений локальных функции с вызовом localFunction initValue 10 в самом её конце.

VE>>Лично мне возможность писать foo bar baz where ... очень нравится. Must have.

VD>Может это и не плохо, но проблемы это не решит ни в каком виде.

Tertium non datum. Проблему надо или решать целиком или не решать вообще?

Здравствуйте, Vaako, Вы писали:

V>1) Генетический способ изложения — почему этот оператор тут появился? Что было раньше? Какие есть альтернативы .
Первое — интересно, но попахивает избыточностью.
V>2) Переход в 3Д, но не UML — нужно удобнее.
А вот это не понятно. Чем 3Д нам поможет?

Здравствуйте, 0x7be, Вы писали:

0>Большой засадой на пути понимания кода является то, что в отличие от большинства естественных текстов, программа не является линейным текстом. У программ нет вступления, сжатого тезисного изложения основных идей, линии повествования и постепенного раскрытия замысла автора. Программы — это клубки связанных понятий, которые ещё и не понятно с какой стороны разматывать. В них не всегда можно быстро выделить ключевые абстракции, уточняющие абстракции, главные пути исполнения и т.п.

Тебе надо смотреть литературное программирование (Д. Кнут). Literate programming.

Там пишешь примерно (показано очень схематически) так:

{Программа, которая выводит массив целых чисел} =
  {Строим таблицу p}
  {Выводим элементы таблицы p}

{Строим таблицу p} =
  {Инициализируем таблицы}
  while k < m do
  begin
    {Увеличиваем переменную j пока она не станет простым числом}
    k := k + 1;
    p[k] := j;
  end;

{Увеличиваем переменную j пока она не станет простым числом} =
  repeat
    j := j + 2;
    {Вычисляем переменные, которые зависят от j}
    {3аносим в переменную j_is_prime результат теста переменной j на простоту}
  until j_is_prime;

// и т. д.

Здравствуйте, Mystic, Вы писали:

M>Тебе надо смотреть литературное программирование (Д. Кнут). Literate programming.
Я знаком с этой концепцией, но по мне она эквивалентна комментированию кода. То есть дублированию информации. Я ищу способ сделать сам код читаемым.

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Mystic, Вы писали:

M>>Тебе надо смотреть литературное программирование (Д. Кнут). Literate programming.
0>Я знаком с этой концепцией, но по мне она эквивалентна комментированию кода. То есть дублированию информации. Я ищу способ сделать сам код читаемым.

Одна из идей в litertate programming все-же лепить код программы из блоков. Если все названия секций заменить идентификаторами, мы получим чистый программный код, иллюстрирующий только эту идею:

{PrimeNumbers} =
  {BuildPrimeTable}
  {OutputPrimeTable}

{BuildPrimeTable} =
  {InitTables}
  while k < m do
  begin
    {FindPrime}
    k := k + 1;
    p[k] := j;
  end;

{FindPrime} =
  repeat
    j := j + 2;
    {Prepare}
    j_is_prime := TestPrime(j);
  until j_is_prime;

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

Здравствуйте, 0x7be, Вы писали:
V>>1) Генетический способ изложения — почему этот оператор тут появился? Что было раньше? Какие есть альтернативы .
0>Первое — интересно, но попахивает избыточностью.

Первые Комиентарии ассемблере также приравнивали к избыточности по сравнением с машинным кодом.

V>>2) Переход в 3Д, но не UML — нужно удобнее.
0>А вот это не понятно. Чем 3Д нам поможет?

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