Мне обычно хватает форматирования кода в visual studio, тогда он становится более читабельным. К тому же есть мнение, что написанные через задницу алгоритмы не будут иметь сильно красивую и наглядную схему, построенную таким образом.
Затея во многом может быть полезной, наверное от того уже многократно решена её задача.
К примеру: FCEditor редактор блок-схем. Позволяет импортировать схемы из кода программы. При этом выравнивание блоков, стрелок происходит автоматически.
P.S. Сам же подобную генерацию нахожу не серьезной и целесообразной только в целях обучения.
Не нахожу смысла строить блок схемы (как и графы) для закрытого кода.
Правильный закрытый код подкреплен грамотной документацией. Не грамотные новички не пишут закрытого кода и тем более не пытаются в нем разбираться.
Конечно должен быть подкреплён документацией, но такое бывает только в сильных командах… А команды, как вы знаете не все и не всегда сильные :)
Т.е. да, хорошая документация, api в @javadoc и комментарии в системе контроля версий должны, просто обязаны присутствовать в проекте!
Но на практике, часто бывают моменты, что увольняется человек, который пилил себе спокойно свои классы, а на его место посадили другого человека, который и должен разбираться в этом спагетти…
Раз уж там макаронная фабрика, то стоит ли продолжить труд бывшего сотрудника?
Если стоит, а код сильно темный, то насколько подобный сервис будет адекватной помощью?
Верно, у меня тоже возникают сомнения, следовательно популярности с такой постановкой задачи ждать не следует.
Если же сервис правильно позиционировать, наметить целевую аудиторию пользователей, тогда и «выхлопа» будет больше.
Как я уже писал выше, адекватность и актуальность сервиса будет только при работе над простым кодом. Но в простом коде и разобраться не сложно. Логика подсказывает область образования. Туда и стоит смотреть. В этом направлении должен быть дизайн, раскрутка, сопутствующие материалы к сервису.
Для небольшого участка обычно и так всё понятно, проблемы возникают в понимании более общих принципов в больших проектах. А алгоритма, угадывающего предназначение целых модулей проекта, наверное не существует. Тут поможет только хорошая проектная документация.
По табуляции — думаю для любого языка найдется правильный форматер, так что это правится одним нажатием хоткея
> Представьте, вы открываете страничку в браузере, пастите туда утомивший вас код, нажимаете кнопку. После чего сайт рисует вам блок-схему алгоритма.
техничего характера вопрос: как вы представляете выдачу блока условного выбора на нажатие кнопки интерфейса?
вот хотя бы «Была нажата кнопка NUMBER?»? -yes> «Вызов PROGS»: -no>
Тут есть некое противоречие. Автогенеренная диаграмма читаема, только если она генерится из ПРОСТОГО кода, как в примере. Очень-очень простого. А если код сложный и диаграмма нужна чтобы в нем разобраться — то автоматически сгенерированная диаграмма почему-то всегда получается настолько монструозной, что разобраться уже в диаграмме не проще, чем в исходном коде без нее :).
ИМХО, осмысленно рисовать диаграмы и схемы по коментариям и только по ним. Наверное, есть специальные разметки комментариев которые позволяют это делать (не doxygen и javadoc для комментирования параметров функций — а именно для объяснения работы кода внутри тела функции ) — но я таких не встречал. Если кто знает — буду очень благодарен за подсказки в какую сторону копать :).
Визуализация кода