heey all, In the past my sourcefiles where never (almost) never bigger then 100 lines. Now i'm building a programm that creates severy files(5) of 400+ lines. And it's getting more and more difficult to find, isolate, and fix bugs. Fortunantly it's easy to find the bug, but finding out WHERE the problem arises is the real trubble. Do any of you people have advice on how to find bugs more easily? If it helps, this is my tool: Microsoft Visual Basic 2010 thanks in advance, assainator

Use the Debugging of Visual ! breakpoints, the Call stack... It's very useful.

[Edited by - 10n02 on December 22, 2009 3:54:06 PM]

The executive summary: Careful design, careful analysis of the failure, a little intuition, breakpoints, and the patience of a saint.

One of the "art forms" of coding is making code that's easy to debug. Coding style has been the subject of many debates here and elsewhere. Personally, to a large part, I'm style agnostic as long as you're following a consistent style, though there are some ideas that I think simply make sense.

If you're struggling to debug ~2000 lines of code, I'm guessing that your code isn't very organized, and that functions are trying to do too much work all by themselves. A rule of thumb from where I work is that if a function is longer than the screen it should be broken up into multiple function calls, usually by isolating bits of functionality within the function into functions that are called by the soon-to-be-more-readable big function. You will discover that debugging is much easier when you can look at the problem and intuitively isolate it to a given system or function because your features are neatly segregated from each other.

Also, learn to use breakpoints. Put the cursor on a line of code and press F9 in Visual Studio. Also, you should be able to click to the left of the line. By default, Visual Studio for VB should highlight the line of code in yellow and place a red circle to the left of it, both indicating that a breakpoint has been set on that line of code and execution will pause when it reaches that line. From there, you can examine variables and even step through the code line-by-line to verify that things are working as you expect.

heey all,

thanks for the reply's. I was already using breakpoints but what is the call stack exactly?

And about splitting functions: the problem is that I have 3 functions wich are just HUGE 'select case'(switch in C++) loops, and are difficult to break down.

A call stack is the list of which functions are calling which functions at the moment of time when you've hit a breakpoint or crash. A.k.a. "the stack of function calls". Look for a way to turn it on when you stop code at a breakpoint.

Look the Call Stack is very useful in this example of case :
Program crash in LoadTexture(...) And you are sure that this function is correct. LoadTexture(...) is call by a lot of objects : Terrain, Character, Model....
Thanks to the call Stack, you'll see that LoadTexture(...), just before the crash, has been call by the object Terrain(for example), so the problem is certainly in the terrain object!