Question

I am working on the project written in c++ that does some manipulations on the text lines. One of the lines causes program to enter infinite loop in on of the functions (2000+ lines of code). The reason is that a conditions, checked by another 2000+ line function fails. I know that if I remove quote symbols in the original line everything works fine (check works fine, no infinite loop). But the logic of these two huge functions is just inconceivable and the person who wrote these methods is no longer available. So, basically, what I am left with is to go step-by-step and compare what’s going with a bad line and a good line, what paths are taken by the program.

Are there any tools, which can print the execution path taken, so I don’t have to compare every step manually? And what is the general technique in grasping the loging of a huge unknown function?

P.S. Using Windong and Visual Studio

Answer 1

I’ve worked on a C++ project with functions over 4000 lines of code in a function, so I feel your pain! I didn’t have the option at the time, but what I would do be to isolate the big functions into a new project so you can play around with them without damaging the main codebase.

Then I’d unit test it to the max, passing in lots of different inputs, and assert that the output is what happens on the first run. Once you’re happy that you’ve covered as much as reasonably possible, then start refactoring. Choose some small bits of the code that you do understand, and extract it into a well named method. Good candidates are if statements with more than one condition, the contents of loops and chunks of code preceded by a comment. Make sure the new function names are self-commenting, e.g. CopyContentsOfStringIntoBuffer()

This helps in a couple of ways – firstly, you’ll be able to see your main functions getting smaller. Secondly, you won’t need to read bits of code you already understand. Thirdly, the code becomes much more readable.

Once you’ve done that for the bits you do understand, you can do a similar thing for the code you don’t understand. Extract it into a new function, and write some unit tests with various inputs and see what the outputs are. Once you understand, rename the function to reflect your understanding.

Keep running your original unit tests to ensure that you don’t break anything during the refactoring.

You can write more unit tests to verify the new functions. Once you’re happy, you can move the code back into the original project (with the tests). Your future self with thank you on a regular basis.