Slashdot Mirror


Visualising Code Structure in Large Projects?

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?"

2 of 47 comments (clear)

  1. Pen and Paper. by spt · · 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.

  2. My story by Kz · · Score: 2, Insightful

    A few years ago, I found myself at a similar situation; I had to port a Bridge game from DOS to Mac. I had the full source code, but it was so old I couldn't make it compile. Even worse, I had never played Bridge!

    I started playing with the executable, and learned the cards game (very boring! never played it again).

    Then I wrote some utilites using .BAT files, the 'Find' command from DOS, and QBasic. Those utilities allowed me to type any function or global variable (there were lots of globals!!) and it would tell me in what file was defined, declared, and what functions used it (with a tree of callers)

    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!

    --
    -Kz-