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

Задача была поначалу для интереса — найти алгоритм поиска замкнутых контуров из произвольно заданного набора кусков кривых. Теория графов по Эйлеру была руководящей идеей. Основным требованием для меня являлось сохранение линейной скорости алгоритма.
Если кто то считает, что задача очевидным образом формализуется в виде классов — прошу на сцену. Я же таких явных классов не видел, а создавать их искусственно, на потребу г-на начальника, считаю бесполезной и даже вредной тратой времени. Я могу сформулировать такой критерий — если классов не видно, то лучше никаких классов, чем что то уродливое, но объектно-ориентированное.
И причин тут по меньшей мере две — 1)алгоритм не расползается по разным местам и файлам, а более менее локализован, что важно при его первичном моделировании, и 2)отладка не настолько утомительна, как в случае классов, да еще с использованием STL-фичей, на ошибки которых компилятор ругается хорошо если 10-этажнвм матом (а чаще просто вываливает на экран половину системных h-файлов), а отладчики в половине случаев не способны показать значение зарытого в классах члена или свойства.

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

Задача была поначалу для интереса — найти алгоритм поиска замкнутых контуров из произвольно заданного набора кусков кривых. Теория графов по Эйлеру была руководящей идеей. Основным требованием для меня являлось сохранение линейной скорости алгоритма.
Если кто то считает, что задача очевидным образом формализуется в виде классов — прошу на сцену. Я же таких явных классов не видел, а создавать их искусственно, на потребу г-на начальника, считаю бесполезной и даже вредной тратой времени. Я могу сформулировать такой критерий — если классов не видно, то лучше никаких классов, чем что то уродливое, но объектно-ориентированное.
И причин тут по меньшей мере две — 1)алгоритм не расползается по разным местам и файлам, а более менее локализован, что важно при его первичном моделировании, и 2)отладка не настолько утомительна, как в случае классов, да еще с использованием STL-фичей, на ошибки которых компилятор ругается хорошо если 10-этажнвм матом (а чаще просто вываливает на экран половину системных h-файлов), а отладчики в половине случаев не способны показать значение зарытого в классах члена или свойства.

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

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

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