   How do you guys deal with debugging hassles?
  I'm not sure if it's because of how rusty I am, but I put ~6 classes together earlier today, making a little program. When I hit Build, the compiler spit out 40 errors (1 hour of work to figure them out), and later when it fixed those, I had to fix 2 more linker errors(15 minutes)  :((This was in Visual C++, which I thought was one of the nicer IDE's out there?)For the high-level stuff at school, we use mostly Java+Eclipse, and I haven't really appreciated it till now. It's much clearer about what the errors mean. It points them out as you type them. It suggests ways to fix them, and can even fix them for you. Overall, it's much more stress-free.I know there's no way to change the errors a C++ compiler spits out, but is there some way to make things easier?   
  The Visual C++ team are making progress on this, but the main issue (thus far) is that C++ is incredibly difficult and expensive to parse.One way is to write less code in one go. It depends on what your build times are like, but if they are manageable (which they should be for small projects) just building more often will mean you get less confusing errors - its easier to understand the root error when the total error output is small.   ;Quote:Original post by meteorstorm42I know there's no way to change the errors a C++ compiler spits out, but is there some way to make things easier?It gets easier with experience. You make fewer typos to begin with, and the process of fixing a syntax error is much more efficient. For a reasonably experienced C++ programmer, 40 syntax errors would only take a few minutes to fix (especially given that only the first few per file are actually meaningful).   ;Quote:Original post by rip-offThe Visual C++ team are making progress on this, but the main issue (thus far) is that C++ is incredibly difficult and expensive to parse.Ooh, shiny! And Visual Studio 2010 is already in beta. That'll be nice to have.Yeah, I guess I'll get better at fixing errors with practice. I just wish they weren't so cryptic :/ I've started taking notes on some of the ones I've run into. Hopefully it'll help fix them quickly in the future...Edit:   What do you guys think of the write-tests-first methodology? Would it help? Or does it just slow down productivity?   ;  Test driven development isn't a magic bullet, and i personally think it's a bad idea for game dev.Often times the tests are made with the same incorrect assumptions as the code, since the tests are often written by the same people who write the code (which is certain in your case!)it's a fad that i think has already faded away a good amount luckily (:   ;  Like Sneftel pointed out, you get more experienced and make less mistakes.Also, you get used to the error messages, what they mean and how to fix them.90% of the times you get the same error message that you know how to fix. And from the remaining 10%, the 40% of those errors are usually common mistakes.Also usually one typo make the compiler throw one error about it, and start compiling the rest wrong, turning into 30 errors because of a missing semi colon.I remember the first time I used GCC, I was clueless about what it was trying to say about my code with it's error messages, I just wasn't used to it.CheersDark Sylinc   ;Quote:Original post by rip-offThe Visual C++ team are making progress on this, but the main issue (thus far) is that C++ is incredibly difficult and expensive to parse.One way is to write less code in one go. It depends on what your build times are like, but if they are manageable (which they should be for small projects) just building more often will mean you get less confusing errors - its easier to understand the root error when the total error output is small.QFEAlso, I'm not a huge fan of test driven development for most things. Many things are simply hard to test (or you don't know for sure/care what your requirements are to write the tests).   ;  IMO,the reason that TDD doesn't work very well in games, is that game-play code is often messy, constantly changing, and often downright hacky. In other words, the Law of Demeter and good data normalization guidelines aren't properly followed, making small tests of individual components too tricky to be worthwhile.In cases where the Law of Demeter is followed though (perhaps in the engine, if not in the game-play code?), TDD is easy to follow and does help productivity.   ;Quote:Original post by meteorstorm42Yeah, I guess I'll get better at fixing errors with practice. I just wish they weren't so cryptic :/ I've started taking notes on some of the ones I've run into. Hopefully it'll help fix them quickly in the future...When they seem cryptic, seriously consider hitting up the MSDN documentation page for the error code -- it often explains the error better, and may even list probable causes of many of them.   ;Quote:Original post by meteorstorm42Edit:   What do you guys think of the write-tests-first methodology? Would it help? Or does it just slow down productivity?It doesn't help with syntax errors. It does help with other bugs. Test-first is primarily useful in the context of a formalized (and actually followed) development methodology. If you're not following a particular process that involves TDD, you may well end up spending more time changing unit tests and wondering if it's the test or the code that's erroneous, than you would debugging the code in the first place.   