Визуализация кода, возможности Visustin в Doxygen

Есть сложный проект для мк на C и хочется в нем разобраться. Планирую это сделать закомментив весь код под Doxygen, но помимо графов вызова функций хочется видеть алгоритм работы каждой, отдельно взятой функции и чтобы в ней так же работали ссылки на объявление, например, глобальных переменных, другие функции если они используются в функции.
Поясню на примере открытой либы от AD, а именно функции ad9361_do_calib_run:

Вот ее описание в doxygen:


Не хватает алгоритма работы функции, со всеми ссылками на используемые функции (как в графе вызовов).
Вот алгоритм работы функции этой же функции, но сгенерированный Visustin:

В Visustin не засунешь весь проект и ссылки, как в Doxygen не предусмотрены.

Можно как-то подружить Doxygen и Visustin? Или может существует другой инструмент, в котором можно описать проект с генерированием визуального алгоритма работы функций?

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

0

Сообщение от Turgenev Планирую это сделать закомментив весь код под Doxygen, но помимо графов вызова функций хочется видеть алгоритм работы каждой, отдельно взятой функции и чтобы в ней так же работали ссылки на объявление, например, глобальных переменных, другие функции если они используются в функции.

непонятно. приведите пример кода который трудно понять и требуется его визуализация

0

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

0

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

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

Ещё одна мысль - о том как программист самосовершенствуется. Просто наблюдение - чем больше программист облегчает себе жизнь при помощи "современных" ide и различных вспомогательных инструментов тем меньше он напрягает свой мозг и тем более расхлябанным становится. И наоборот - если у вас нет таких инструментов - вы вынуждены самодисциплинироваться, писать код который хорошо структурирован, понятел и прост. Вам не будет лень написать название функции на 100 символов только для того чтобы код легко читался - как английский технический текст. по сути код станет самодокументированным - вам самому будет это нужно.

Ещё мысль - не все алгоритмы вы сможете представить графически так чтобы их понять. Я вот недавно писал конечный на примерно 60 состояний, притом некоторые состояния обрабатывались через пул потоков. писать это через switch это то ещё удовольствие. А вот применив указатели на функции, которые хранились в массиве по номеру состояния - самое оно. Вот и представьте как это визуализовать чтобы было понятнее. скорее всего будет ещё менее понятно.

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

заруглите "Semantic Compression" - там описан очень интересный приём который позволяет программисту работать с кодом.
Но опять таки - для мыслительного процессы если вы будете в голове оперировать графическим представлением алгоритмя - то вы будете постоянно в мозго трунслировать из одного представления в другое, а это не эффективно. ( разьве что вы будете писать на FBD или SFC )

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

1

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

0