Visualising Code Structure in Large Projects? 47
TheMaccLads asks: "I've recently joined a new C++ project, and it's in a terrible state. There are 100-odd source directories, dozens of libraries, and a couple of dozen executables and DLLs. Some executables pull in (i.e. compile themselves) the occasional source file from a library, instead of using the libraries. My job is to port a subset to unix, but I need a tool to visualise all the relationships between directories, projects, libraries, and so on, because my brain will overheat soon otherwise. Preferably a tool that will do it by parsing the MS Dev studio projects and workspaces, but if I have to write it myself in Perl, I will! Anyone know of any tools? Or suggest an approach?"
Sounds rough (Score:1, Interesting)
Rational may have some software as well...
Visio's definitely the way to go, though.
Re:Sounds rough (Score:1, Interesting)
Re:Sounds rough (Score:1, Interesting)
Pen and Paper. (Score:5, Insightful)
Really! Just start drawing lines and boxes as you delve through manually. If you get something to do it automatically, you still won't have a good visualisation in your head.
Re:Pen and Paper. (Score:1)
yes
This might seem like hard work, but I've discovered 2 things
1) Spending some time like this up front will save you loads of time later. And saved time is lazy time.
2) If you do something proactive at the start of a project, then everyone else thinks you are wonderfully energetic. If you build up some workplace brownie points now, you can squander them through laziness later.
Rational Rose (Score:1, Informative)
Hmmm (Score:2, Informative)
Theres other products out there too, All are expensive.
Perl's the Solution (Score:1)
It went through all files and printed a nice graphical output (with gd?) with all functions in bubbles with connections all over.
Should be possible to modify for C++.
Some other solution (Score:2)
Doxygen (Score:5, Informative)
Re:Doxygen (Score:5, Informative)
Get it. [doxygen.org]
I wish it supported python, which is the other OO language I routinely use.
Am I missing something? (Score:2)
Unless I overlooked something, the only diagrams Doxygen draws are class hierarchies. Unless you have a lot of classes, I can't see bothering with a whole big app just for that.
Doxygen sounds like it's handy for generating API docs with a minimum of effort, but pretty useless for analyzing mysterious legacy code.
Yes you are missing something (Score:1)
Re:Am I missing something? (Score:2, Informative)
The class hierarchies are very sophisticated. For example, you can see a page with a summary of all the methods for a derived class showing where all of these methods are inherited from. The same view shows all the attributes on each method, such as virtual, inline, static, etc.
There is also a whole section generated on include file hierarchies. You can see quickly where everything is declared without doing a bunch of greps to try to see how things fit together.
Finally, the hyperlinking scheme is simply inspired. For example, it will even take you to the exact line of a header file that corresponds to a particular method (complete with syntax highlighting).
Go look at it. It's not going to reverse engineer design documentation from the intent of the code, but it gives you a huge advantage over a big pile of C++ files. (If you think you are going to find a tool that does the former, you're smoking something.)
McCabe Visualization tools (Score:3, Informative)
Their software will also help re-engineering and testing efforts: it'll tell you how complex your code is (and thus what parts of it are most likely to break), and it'll instrument your source code and show you what logic paths you've hit in your program during testing, and what code remains untested. It used to be pretty solid stuff (and pretty pricey!); I'd love to see some free/open software that does stuff like this.
Disclaimer: I'm a former intern.
Re:McCabe Visualization tools (Score:1)
Me too, but I doubt it will ever happen. This is not the kind of effort that interests the open source development community, since the projects they work on are (on the whole) not large enough to warrant such tools.
I saw some evidence that the X-Consortium have started to use Rational ClearCase for their conf mangaement, I would love to see a free tool with the capabilities of ClearCase, but again Open Source developers have other more interesting things to work on.
A HUGE whiteboard (Score:1)
Understand (Score:1)
CodeWright for mapping (Score:4, Informative)
It is the best editor I have seen yet (multiple language support, totally configurable, excellent tech support), and it is great for navigating large projects. It parses all of the files in your project as text (so you can browse code that does not compile), and is a good complement to Dev Studio's build-based browsing.
It integrates with Dev Studio, so the two editors and environments will update each other when you switch between them.
I probably shouldn't admit this on /., but at one job, I had a Windows box dedicated to running CodeWright, editing QNX code over Samba. It was actually worth the extra box. At another job, I was using it to edit files for Sun and DEC UNIX (no Samba this time), and it was still worth it to ftp the files back and forth, rather than use what I could find in the UNIX world at the time.
I know also that there is some really good code mapping software out there, but I can't give you any names off of the top of my head. Large sheets of paper really do the trick, though. I have seen people spend a lot of time with visio getting very little done, but I haven't used it myself, so don't listen to me and I'll shut up now.
Re:CodeWright for mapping (Score:1)
Code Surfer (Score:1)
Is commercial software though.
My story (Score:2, Insightful)
I started playing with the executable, and learned the cards game (very boring! never played it again).
Then I wrote some utilites using
It took me a couple of days to write the utilities, and proved really lifesaving
after that, I used paper. If there was a long function with lots of nested loops and goto's (it was C, but looked like bad basic); I would print it and tape the paper to the wall. Then just spend hours looking at it, pencil at hand, drawing arrows and notes over the code
Very slowly, I separated the engine from the UI and IO code.
Then I just wrote a new application on the mac, that called the old engine code. Of course the game gained a lot of mouse manipulability, sound effects and even a video intro (without QuickTime, of course)
In short, first craft your tools, then use them. Spend lots of time just looking at the code. Slowly the hate will melt into pity for it, then your job will be to liberate it!
Re:My story (Score:1)
Just curious. If you re-wrote it from scratch, do you think the result would be quicker and/or better than reverse-engineering a mess like that?
Re:My story (Score:1)
Remember, I barely knew how to play bridge, I wouldn't try to reimplement the inference engine that chose which cards to play. That code had lots of years of debugging and real world exposure in there.
All the analisys was to separate the core (untouchable) from the UI and IO and re-creating the environment it needed to work
CDOC by Software Blacksmiths (Score:1)
This works pretty well
http://softwareblacksmiths.com/
Post-It notes and a DryErase Board, Bake at 350 (Score:3, Funny)
3 Afternoons
1 Huge Pile of Code
2 Large White-boards
3 small little cubes of those MultiColored post-ITs
2 Handfuls of assorted colors DryErase markers
Start by pouring all the ingredents into a medium sized classroom-type-room with lots of chairs and a small assortment of refreshments. (Be sure to wash off the white board.) Tell all the people what you are trying to do and tell them they will have to help you out for at least one afternoon over the next couple of days. [Whatever. Intimate time with code. They'll learn something. You'll get to talk to eachother.] Tell some they have to stay, others they'll have to help you tomorrow, etc. Look over the code and decide which portion you'd like to work with today. Isn't it pretty? Now - by applying the markers and the PostITs to the White-board, carefully extract the useful parts of the code, leaving the nasty, hairy choke behind. Go for the structure. Go for the connections. Dispose what is leftover. Take a high resolution picture. Go home and get some sleep.
Repeat the above for each piece of the program you'd like to work on for each particular day. After you have extracted all the good, and none of the bad, combine the extract with your wonderful programming skills, the sarcastic cheers from your friends in nearby cubicles, and big high-resolution printouts of your photography work in a CPU Unit Processor, blending until firm. Chill, Serve and Enjoy!
Re:Post-It notes and a DryErase Board, Bake at 350 (Score:2)
First, you forgot to include the disgruntled Evil Janitor in your list of people, for a total of 6.
Insert the following step before "Repeat the above...":
"Evil Janitor swaps around pretty colored paper squares in the middle of the night."
snavigator (Score:1, Interesting)
rpm's for most distros.
Great tool for what you're talking about. I'm just surprise no one else mentioned it.
-Jay
Re:snavigator (Score:1)
What I want... (Score:2)
Re:What I want... (Score:3, Informative)
Although this seems like a convoluted feature, it's extremely useful for doing any kind of refactoring work where you want immediate feedback analysis. You get to see immediately where everything is used, and it's got other tools which help with that as well (like the class browser and the like). (It also has Visual Basic-style autocomplete, which I absolutely love, because on large projects I never remember exactly what everything's named).
Admittedly, you might not want to change editors just for this feature, but you might want to have it in your arsenal of tools for when you do need/want it.
no real shortcuts (Score:2)
Source Insight... (and 30 day free eval) (Score:2)
The bonus is that it runs very fast, is useful as an editor, and knows enough about all your code to do smart things like smart-gloabl-rename, find all references to symbols, etc.
They do a 30 day free eval too...
T
Visualising Code Structure in Large Projects=ROSE (Score:1)
Together (Score:1)
Also, to find references to particular methods and subroutines, LXR [linux.no] is very useful. LXR is designed for use with the Linux codebase, but it is generic enough to be used with any C/C++ project. It takes a couple of hours to get running, but it is free and very cool. I just wish it would support Java.
DOC++ (Score:1)
Doxygen (Score:1)