Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17
  1. #11
    Join Date
    Jul 2006
    Location
    San Diego, CA, USA
    Posts
    897
    I would highly encourage all coders to take advantage of (ie. LEARN!) the built-in debuggers that their IDEs contain. I'm assuming you are using an IDE that has one. Even Linux has debuggers for IDEs. Favor the debugger instead of printf(). There are only a small handful of things you need to know in order to gain the power over finding and fixing bugs. Breakpoints, variable watch windows and call stack to mention a few are indispensable tools you should, as coders, get very familiar with. In fact, I rely on them so heavily that if taken away I would most likely stop coding. They are that important. Besides printf()s tend to get speckled all over the place and may get forgotten when releasing the final code. That said, I do use them but only very occasionally. In fact I can't think of a good reason why I choose them over the debugger at the moment. (pause - I just thought of one) They are good when you want to watch variables over time that change often. Conditional breakpoints can be used here but sometimes just seeing the values changing in the console or other diagnostics window you may have written is valuable too.

    I guess I get on my soap box about proper code debugging, and I mean proper today since we have these tools. Back in the day when my father was programming via punch cards on main frames they didn't have this luxury. So I'm not saying printf is bad per se, just don't limit yourself to ONLY using that approach.

  2. #12
    Join Date
    Jun 2003
    Location
    Trier, Germany
    Posts
    1,350
    even better: use tests.

    (this is mainly an advice for those who have a few years of programming experience. beginners are usually better off learning proper use of the debugger first)

    whenever you would write a log entry, write a test instead. there are a number of decent testing frameworks out there (googletest being the most promising at the time imho) and even visual studio has test support in vs2010 and will provide further testing facilities with vs2011.

    unfortunately, writing good tests is almost as hard as writing good programs. on the other hand, learning to write good tests usually also improves your general software design skills a lot, so it's probably worth the effort

  3. #13
    Join Date
    Oct 2009
    Posts
    28
    SMJones: With that said, you cannot debug an application that someone else is running on another computer. Also, if you are not expecting a bug/error, a console out (changed to an error log at release, of course) can reveal to you the underlying issue without having to re run the program again. This is especially useful when you have an obscure issue that takes quite a while to replicate (ie: Halfway through this level when you push this button, if you have this weapon, and there are two enemies left)- it is useful to see the exact flow of the program without expecting to need it. The debugger is certainly more viable for small scale programs, and very much even large scale ones, but you cannot rely just on one or the other (as you previously said).

  4. #14
    Join Date
    Jul 2006
    Location
    San Diego, CA, USA
    Posts
    897
    you cannot debug an application that someone else is running on another computer
    Actually you can and its called remote debugging. Given the same exe and the accompanying symbols that were built with that exe I can debug your app running at your desk while I sit across the country watching it run in my IDE on my computer (assumes Visual Studio for this example). I've done this actually, debugged an app running in Singapore while I sat in the US. This works if you have the symbols, of course. Works great for native and managed apps.

    I did not mention logging which can be another form of debugging especially if you are dealing with released code and you do not have access to its symbols. Your example of the obscure issue may be best served by using logging. When I refer to using printfs I mean the classical writing out variable and other state information to the console at runtime. Many people do this even though they have a powerful debugger at their disposal. Its like a song that says "I'm playing GameBoy standing in the middle of the Grand Canyon, I'm eating candy sittin' at a gourmet feast"! If its there, learn how to use it.

    Debugging is not just for small scale programs. We have multi-threaded and multi-project applications that are very, very large, millions of lines, and we still use the built-in debugger for many things.

  5. #15
    Join Date
    Oct 2009
    Posts
    28
    I had no idea... WOW! Does the other person have to know your debugging it?

  6. #16
    Join Date
    Jul 2006
    Location
    San Diego, CA, USA
    Posts
    897
    Quote Originally Posted by Scyth3s View Post
    I had no idea... WOW! Does the other person have to know your debugging it?
    Well we did it cooperatively of course. That is because a breakpoint on my end can and will actually stop the program on their end.

  7. #17
    Join Date
    Oct 2009
    Posts
    28
    Haha owned! Thats really cool.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •