Tools For Understanding Code?

ewhac writes "Having just recently taken a new job, I find myself confronted with an enormous pile of existing, unfamiliar code written for a (somewhat) unfamiliar platform — and an implicit expectation that I'll grok it all Real Soon Now. Simply firing up an editor and reading through it has proven unequal to the task. I'm familiar with cscope, but it doesn't really seem to analyze program structure; it's just a very fancy 'grep' package with a rudimentary understanding of C syntax. A new-ish tool called ncc looks promising, as it appears to be based on an actual C/C++ parser, but the UI is clunky, and there doesn't appear to be any facility for integrating/communicating with an editor. What sorts of tools do you use for effectively analyzing and understanding a large code base?"

Wait for cenqua's solution

[ccguy]

I hear that the commentator [cenqua.com]guys are finishing a new product that instead of commenting your code is able to comment other's.

Old School

[geekoid]

Printouts and colored markers.

You must have inherited my old project

[theophilosophilus]

Sorry about that.

Answer

[hey!]

Yes. Understanding code is one of thing things you hire tools for.
...

Wait, were you talking about software?

I have an idea

[Anonymous Coward]

You could try posting the code here and maybe some kind people at slashdot can help.

Re:When I was your age...

[Mr. Underbridge]

When I was your age...I use the Mark I eyeball, grep, emacs, and of course, the little gray cells.

(and GET OFF MY LAWN).

They have lawns at the old folks' homes these days?

Re:Umm.. documentation?

[Skewray]

Why? I can write crap and you can clean it up. This is Division of Labor, which is the basis of our civilization.

Re:How / why did you get the job...

[PetriBORG]

Only 1600 lines?

I used to work at a company with a lot of Pascal and C code... It was extremely common (as in, all but a few) for programs to be written entirely in one code file. These files would go on for 20,000 lines or more. So many lines in fact that after the compiler had imported the header files at the top of the file that they would be over 65,000 lines long and the debugger would crap out because it had exceeded the int that it used for line number counting.

Sadly this isn't a joke.

Re:Paper

[sdpuppy]

Well when all else fails, look at the variable/function/structure names.

Obviously a program with labels such as "Frodo" Sam" "Gondor" must be doing something Lordly with rings

and if you have labels such as "string1" "string2", then the program must be solving some particle physics problem involving string theory.

... and when that fails, you go back to your old college, find the smartest CS geek and slip him/her a few dollars to figure it out.

Need I add :-) :-) :-) ?

Solution

[Chapter80]

I've always found that the most effective method of learning code is to inject a random line of code somewhere, and see what breaks. Two techniques: 1) print some official-looking error message, and 2) add a large value (a million or greater) to a number somewhere. Keep a nice chart of what you added, where:

Error 'Format Conversion Error, converting from Y2K to Z2L' added to module x1
Error 'Out of Memory Banks' added to module x2
Error 'Object Expected; found adjective instead' added to module x3
Error 'bitbucket 95% full; please empty' added to module x4
Added 1,000,042 to some random value in module x5
Added 5,555,555 to some random value in module x6

Not only will you learn about the code, you'll make a great impression on your boss, when, within minutes, you are able to resolve some mysterious problem that has never happened before.

Re:Stepping Through

[doti]

.

worse

advice

ever

Re:Been there...

[seanadams.com]

Not everything is a duality.

Ah, so really there are two kinds of things: those which are dualities and those which are not?