Может ли быть спагетти-код не на основе goto?

@Etyuhibosecyu · Регистрация: 13.07.2017

Студворк — интернет-сервис помощи студентам

Согласно Википедии:

Спагетти-код (также индусский код) — плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, особенно содержащая много операторов GOTO ...

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

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

Может ли быть, например, спагетти из рекурсии? Если да, то это даже хуже, чем из goto, так как goto имеет высокую производительность, а "многосвязная" рекурсия не оптимизируется компилятором. Например, если бы я попытался, как требует книга "Чистый код", разбить этот метод на множество "компактных", не получилось бы спагетти из рекурсии? Думаю, очень вероятно.
Также, мне кажется, может быть спагетти на уровне зависимостей между классами, и именно его я сейчас пытаюсь распутать в .NStar. sau, вы не согласны с этими двумя пунктами?

@sau · 03.05.2025, 20:35

Сообщение от Etyuhibosecyu

вот я сократил список параметров выносом не самих методов в отдельный класс, а групп параметров в структуры. Это приемлемый вариант?

закиньте ваш файлик BigList.cs в какой нибудь copilot / chatgpt / deepseek / meetcode и т.п , попросите провести декомпозицию и рефакторинг , Вам все подробно пояснят , где проблема , как исправить и т.п.
- не в слепую конечно стоит следовать , но направление будет задано верно.

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
BigCollections.NStar/ deepseek version
├── BigList/                 # Основной класс и интерфейсы
│   ├── IBigList.cs          # Интерфейс списка
│   ├── BigList.cs           # Основная реализация
│   └── BaseBigList.cs       # Базовый абстрактный класс
├── Structure/               # Внутренняя структура данных
│   ├── BigListNode.cs       # Узел дерева
│   ├── LeafNode.cs          # Листовой узел
│   └── BranchNode.cs        # Ветвистый узел
├── Operations/              # Операции со списком
│   ├── CopyOperation.cs     # Логика копирования
│   ├── InsertOperation.cs   # Логика вставки
│   └── RemoveOperation.cs   # Логика удаления
└── Utils/                  # Вспомогательные классы
    ├── CapacityManager.cs   # Управление емкостью
    └── Verifier.cs         # Валидация состояния

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
BigCollections.NStar/ copilot version 
├── Models/                   # Модели данных
│   ├── BigListModel.cs       # Представление списка
│   ├── NodeModel.cs          # Представление узлов структуры
│   ├── OperationModel.cs     # Представление операций
├── Interfaces/               # Интерфейсы
│   ├── IBigList.cs           # Интерфейс списка
│   ├── INode.cs              # Интерфейс узлов структуры
│   ├── IOperation.cs         # Интерфейс операций
├── Services/                 # Логика работы со списком
│   ├── BigListService.cs     # Управление списком
│   ├── OperationService.cs   # Управление операциями (вставка, удаление)
├── Repositories/             # Управление данными
│   ├── BigListRepository.cs  # Логика хранения списков
│   ├── NodeRepository.cs     # Логика хранения узлов
├── Utils/                    # Вспомогательные классы
│   ├── CapacityManager.cs    # Управление емкостью
│   ├── Verifier.cs           # Валидация состояния
│   ├── MemoryManager.cs      # Управление памятью

@Etyuhibosecyu · 03.05.2025, 22:25 **[ТС]**

Сообщение от sau

закиньте ваш файлик BigList.cs в какой нибудь copilot / chatgpt / deepseek / meetcode и т.п , попросите провести декомпозицию и рефакторинг , Вам все подробно пояснят , где проблема , как исправить и т.п.

А если к первым двум у меня нет доступа, доступ к третьему я даже не знаю, где искать, а про четвертый вообще и не слышал?

Сообщение от sau

BigCollections.NStar/ deepseek version

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

@Элд Хасп · 04.05.2025, 11:08

Сообщение от Etyuhibosecyu

длинный метод - это меньшее зло, чем спагетти из рекурсии?

Не вникая в остальную дискуссию.
"Длинный метод" - это уже сам по себе "спагетти".
В идеале код метода должен быть не более 1 экрана редактора.
В крайних случаях - 2 экрана.

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

@Катафалк · 04.05.2025, 22:02

Сообщение от Etyuhibosecyu

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

Как раз для таких случаев придумали придумали гугл

@alecss131 · 04.05.2025, 22:47

Сообщение от Элд Хасп

В идеале код метода должен быть не более 1 экрана редактора.
В крайних случаях - 2 экрана.

Довольно абстрактное утверждение, ибо экраны у всех разные.
В нормальных редакторах для горизонтали есть линия, ее настройки не стоит трогать и не стоит выходить за нее. Обычно это вроде 80 или 120 символов в строке. Странно что в студии нету такого...

@Элд Хасп · 04.05.2025, 23:09

Сообщение от alecss131

Довольно абстрактное утверждение, ибо экраны у всех разные.

А само понятие "спагетти код" не абстрактное, а прямо конкретное?
Понятно же что здесь не будет критериев типа "100 строк нормально", а "101 это уже слишком много".

Если код метода растянут на несколько экранов, то для его анализа придётся проматывать эти экраны то вверх, то вниз. Что явно ухудшит понимание его логики и увеличит вероятность ошибок.
В случаях когда его код можно разбить на отдельные блоки, но нет смысла выносить эти блоки в отдельные методы, так как больше они нигде не понадобятся, в Шарпе (не только) можно несколько улучшить читаемость такого метода за счёт его фрагментирования в скобках { some code }. Но это не радикальное улучшение, а выбор "наименее худшего".

@Wolfdp · 04.05.2025, 23:50

Сообщение от alecss131

В нормальных редакторах для горизонтали есть линия, ее настройки не стоит трогать и не стоит выходить за нее. Обычно это вроде 80 или 120 символов в строке. Странно что в студии нету такого...

Расширениями можно доставить. Да и не сказал бы что он прям жизненно необходим. Практически на всех проектах что тусил колеги как-то умудрялись и без линеечки не шибко раздувать код в ширь. Самим же потом в этом ужасе и ориентироваться.

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

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

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

Сообщение от Элд Хасп

можно несколько улучшить читаемость такого метода за счёт его фрагментирования в скобках { some code }

Для ТСа и других -- ещё можно группировать через #region, причём не только внутри метода, а внутри класса или даже всего файла.

@Элд Хасп · 05.05.2025, 01:09

Сообщение от Wolfdp

Для ТСа и других -- ещё можно группировать через #region, причём не только внутри метода,

#region не ограничивает видимость локальных переменных.
Смысл { some code } именно в том, чтобы ограничить логику только этими скобками. Все переменные объявленные в них видны только в них и это увеличивает вероятность, что из этого фрагмента нет "спагеттин" в другие фрагменты кода.

Добавлено через 1 минуту
"спагеттин" - как правильно назвать одну спагетти? Другого в голову не пришло.

@Etyuhibosecyu · 05.05.2025, 01:11 **[ТС]**

Элд Хасп, Wolfdp, мой метод и так не "линия", он состоит из множества условий, в каждом свои переменные. Но сейчас уже я разбил на множество методов.

@Элд Хасп · 05.05.2025, 01:25

Сообщение от Wolfdp

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

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

Здесь конечно не проведёшь границу 50 строк - хорошо, а 51 - уже плохо.
Читаемость, запоминаемость кода метода - это и есть критерии.
Но код метода в 500 строк.... на мой взгляд это без вариантов слишком много.
Я видя такой длины метод, скорее всего, даже не начну пытаться в нём разбираться, если это прям не жизненно необходимо.

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

Сообщение от Etyuhibosecyu

о сейчас уже я разбил на множество методов.

Я бы посоветовал каждый метод сопроводить подробными XML тегами документации.
Посмотрите пример здесь: Библиотека элементов для реализации WPF MVVM Решений [WPF, Элд Хасп]

Это намного упростит использование вашего класса другими разработчиками.

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

Сообщение от Etyuhibosecyu

мой метод и так не "линия", он состоит из множества условий, в каждом свои переменные.

Я сразу предупредил, что моё замечание общего характера.
В конкретику вашего вопроса я не углублялся, код метода смотрел очень поверхностно.

@Wolfdp · 05.05.2025, 20:41

Не по теме:

Хм....

ТС: гайс, как лучше оформалять код?
форумчанин: дробим по методам, вот пример, вот аргументы почему так лучше делать
мимокрокодил: О нет, ваш пример не пример, мне ничего не понятно, вы запрещаете мне говнокодить!

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

@Элд Хасп · 06.05.2025, 11:52

Сообщение от Uswer

в данном ЯП есть явные границы блока кода, т.е. скобки {}

{} не являются обязательными. Но блок кода в case даже без этих скобок явно определён.

Сообщение от Uswer

Ой, да ладно Вам, на заре появления ЯП там скорее всего сделали через тот же Goto,

Ну, мало ли как и что было реализовано.
Я говорил несколько о другом.
Что я не настолько погружен в эту тему, чтобы аргументированно настаивать на той или иной версии. Когда выбирали концепцию, то наверняка разработчики Шарпа обсуждали многие варианты, + и - каждого.
И чтобы аргументировать свою позицию, надо как минимум быть в курсе этого обсуждения. Я не в курсе. Поэтому мои предложения носят чисто умозрительный характер.

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

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

Может стоит официально предложить такие изменения.
Я несколько раз предлагал внести изменения, но их не поддержали.
Из того что помню: дженерал конструкторы, partial автосвойства. Что-то ещё предлагал, но уже не помню что именно.

@Элд Хасп · 08.05.2025, 14:12

Etyuhibosecyu, возвращаясь к теме (наверное тему зачищу).
В данном случае вас интересует только Спаггети-код или любой "плохой" по оформлению код?

Если только Спагетти, то речь имеет о нём вести смысл только в рамках его определения.
То есть как минимум надо понимать что такое структурированный, лёгкий для чтения код в понятиях СООБЩЕСТВА разработчиков.
Если кому-то понятен его собственный код и он считает его струтурированным по одному ему понятным признакам, то это не означает, что он является таким же для СООБЩЕСТВА.
К сожалению дискуссия свалилась в область "Я художник - я так вижу" под влиянием всем известного персонажа. Поэтому последние посты я думаю вынести в отдельную холиварную тему.

Также, если мы говорим ТОЛЬКО о Спаггети-код, то нужно отличать от него другие "плохие" коды: Равиоли-код, Пахлава-код или Лазанья-код, Пицца код, Катамари-код. Возможно есть ещё и другие.

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

@Элд Хасп · 08.05.2025, 14:28

Комментарий модератора

Тема зачищена от оффтопа.
Оффтоп посты перенесены в тему:
Холивар темы: Может ли быть спагетти-код не на основе goto?

Новые блоги и статьи Все статьи Все блоги /
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .
Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .

@Etyuhibosecyu Труд вопреки насмешкам 363 / 181 / 41 Регистрация: 13.07.2017 Сообщений: 4,845 Записей в блоге: 14
	05.05.2025, 01:11 [ТС]
	Элд Хасп, Wolfdp, мой метод и так не "линия", он состоит из множества условий, в каждом свои переменные. Но сейчас уже я разбил на множество методов. 0

@Wolfdp 3790 / 1767 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	05.05.2025, 20:41
	Не по теме: Хм.... ТС: гайс, как лучше оформалять код? форумчанин: дробим по методам, вот пример, вот аргументы почему так лучше делать мимокрокодил: О нет, ваш пример не пример, мне ничего не понятно, вы запрещаете мне говнокодить! Можно абсолютно спокойно игнорить рекомендации, никто в 3 часа ночи с топором к вам не постучится из-за этого. В командной разработке очень быстро распрощаются за неспособность писать нормально. При попытке опубликовать свой код, будет ровно таже история, что и у ТСа. 0

@Элд Хасп Модератор 16166 / 11286 / 2892 Регистрация: 21.04.2018 Сообщений: 33,175 Записей в блоге: 2
	08.05.2025, 14:12
	Etyuhibosecyu, возвращаясь к теме (наверное тему зачищу). В данном случае вас интересует только Спаггети-код или любой "плохой" по оформлению код? Если только Спагетти, то речь имеет о нём вести смысл только в рамках его определения. То есть как минимум надо понимать что такое структурированный, лёгкий для чтения код в понятиях СООБЩЕСТВА разработчиков. Если кому-то понятен его собственный код и он считает его струтурированным по одному ему понятным признакам, то это не означает, что он является таким же для СООБЩЕСТВА. К сожалению дискуссия свалилась в область "Я художник - я так вижу" под влиянием всем известного персонажа. Поэтому последние посты я думаю вынести в отдельную холиварную тему. Также, если мы говорим ТОЛЬКО о Спаггети-код, то нужно отличать от него другие "плохие" коды: Равиоли-код, Пахлава-код или Лазанья-код, Пицца код, Катамари-код. Возможно есть ещё и другие. Добавлено через 5 минут P.S. Добавлю. Спагетти код не является всегда злом. Да это "плохой" код, но иногда это бывает неизбежное зло. Правда такое бывает в исключительно редких случаях. Например, когда струтурированность и читаемость кода принесены в жертву оптимизации по скорости кода. Такое бывает изредка в каких-то библиотечных методах рассчитанных на массовое и частое применение, но не рассчитанных на дальнейшую поддержку и модернизацию. Допустимо такое только для опытных разработчиков пользующихся большим доверием в сообществе разработчиков, так как проверка, тестинг таких кодов крайне затруднительны. 1