Как стать автором
Обновить

Комментарии 25

НЛО прилетело и опубликовало эту надпись здесь
Мне обычно хватает форматирования кода в visual studio, тогда он становится более читабельным. К тому же есть мнение, что написанные через задницу алгоритмы не будут иметь сильно красивую и наглядную схему, построенную таким образом.
НЛО прилетело и опубликовало эту надпись здесь
Затея во многом может быть полезной, наверное от того уже многократно решена её задача.

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

P.S. Сам же подобную генерацию нахожу не серьезной и целесообразной только в целях обучения.
Нет!..

Очень страшно отдавать сервису закрытый код, потому что коммерческая тайна.
Тем более, если код был написан кем-то не очень опытным…

А вот локальный софт — это другое дело… Но думаю тут надо покопать в сторону графов…
я говорю о небольших фрагментах кода. скажем, до 100 строк. Вряд ли такая утечка может быть критичной.
в 100 строках кода можно разобраться без блок-схем, если это не особо спагетти…
Не нахожу смысла строить блок схемы (как и графы) для закрытого кода.
Правильный закрытый код подкреплен грамотной документацией. Не грамотные новички не пишут закрытого кода и тем более не пытаются в нем разбираться.
Конечно должен быть подкреплён документацией, но такое бывает только в сильных командах… А команды, как вы знаете не все и не всегда сильные :)

Т.е. да, хорошая документация, api в @javadoc и комментарии в системе контроля версий должны, просто обязаны присутствовать в проекте!

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

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

По табуляции — думаю для любого языка найдется правильный форматер, так что это правится одним нажатием хоткея
Мне почему-то представилось внедрение xml-комментариев в код (как в C#) на основании которых программа могла бы строить блок-схему, например:

///Пиво привезли
if (beerExists) {… } else {… }

И это место программа отображала бы соответствующим образом
Было бы удобно.
имелось ввиду:
///<if>Пиво привезли?</if>
if (beerExists) {… } else {… }
сложновато получиться
на чём пишите под веб?
php
> Представьте, вы открываете страничку в браузере, пастите туда утомивший вас код, нажимаете кнопку. После чего сайт рисует вам блок-схему алгоритма.

техничего характера вопрос: как вы представляете выдачу блока условного выбора на нажатие кнопки интерфейса?
вот хотя бы «Была нажата кнопка NUMBER?»? -yes> «Вызов PROGS»: -no>
web сервис плох уже тем, что многие фирму запрещают работникам пересылку кода (в любом виде) в Интернете. тем более на публичный сервис.
Тут есть некое противоречие. Автогенеренная диаграмма читаема, только если она генерится из ПРОСТОГО кода, как в примере. Очень-очень простого. А если код сложный и диаграмма нужна чтобы в нем разобраться — то автоматически сгенерированная диаграмма почему-то всегда получается настолько монструозной, что разобраться уже в диаграмме не проще, чем в исходном коде без нее :).

ИМХО, осмысленно рисовать диаграмы и схемы по коментариям и только по ним. Наверное, есть специальные разметки комментариев которые позволяют это делать (не doxygen и javadoc для комментирования параметров функций — а именно для объяснения работы кода внутри тела функции ) — но я таких не встречал. Если кто знает — буду очень благодарен за подсказки в какую сторону копать :).
если кусок кода написан через задницу, его визуализация вряд ли сильно поможет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории