Debugging 101

Contributed by Honey (Web Apps & Mobile Apps Developer)

Debugging 101

As a developer, more than coding, what I enjoy most doing is debugging. Yes, you read that right. It is pretty much of a headache in reality, but once you get it all fixed and running, the feeling is just totally rewarding. So for those who are currently stuck with a bug or you find one in the future, I want to share with you some practical tips on what I do whenever I encounter one. I know most of these are simple and obvious., But I’ve known people who sometimes forget or who don’t know where to begin. So you can have this list as a reminder too.

  1. Ask your bestfriend – Google.

    It is a known fact that you can find almost everything using Google. May it be a recipe, a location, how-to-do-anything-stuff, and, of course, an error code. Asking our friendly Google is a great shot in finding what it is and how you can fix it. All you got to do is search for the right terms. And voila! The answer to your week-long bug would just be right around those lines already. You can even just copy-paste the exact error message and about 90% of the time, there will be results that are related and helpful to your glitch.

    Note though that not all search results in Google are reliable. You should know which sites you should follow. From my experience, my first in the list would be stackoverflow.com, followed by library APIs, github wikis, Google group forums, and the like.

  2. Learn to read.

    Error messages are most of the time very descriptive of where the error occurred and the cause of it. Looking at the error stack may be intimidating at times, but it’s something every developer must learn to read. Understand what the error is saying, what file, what line, and what function the error is pointing to. Know which ones in the error stack is important to you and try to find which part of it was the real cause of the bug.

    You can find these error messages on the logs when you try to run your application. In development mode, these logs are usually in the console. But in production mode, you would need to look them up in the server where your application resides in. Make sure you know where to find these logs or you can ask your system administrator for them.

    Notes:

    1. For server-side errors, they are usually under the /var/log/<server>/error.log folder (for Unix-based servers).
    2. For JavaScript errors, you can find it in the JavaScript Console when you do a right-click on the browser and choose Inspect Element.
  3. Know your tools.

    There are a lot of debugger tools out there. Most of them are even free. You may not know it but the IDE (Integrated Development Environment) that you’re using might have a debugger built into it too (NetBeans, Eclipse, RubyMine, etc). If you haven’t tried it yet, here are some really cool features that I like in using a debugger:

    1. Change variable values on runtime
    2. Watch variables so you would know when their value change
    3. Conditional breakpointing where you could choose to have your breakpoint only when a condition is met
    4. Check the call stack anytime

    Personally, I don’t prefer using debugger tools. Yes, they are very dynamic but they are really tedious for me to use. But, it’s a matter of preference so give it a go.

  4. Practice the art of printing.

    This is my favorite technique in debugging. Don’t laugh just yet. Logging/printing messages in between lines or inside functions not only helps you debug your codes, but they can also tell you important things about your application even when outside the debugging context. For me, it helps a lot in knowing which part of my code caused the error and, when variable values are placed in the messages, it tells me a great information on what may be the cause of the bug.

    Here’s a word of caution though. Make sure you place print messages in key places and not, literally, everywhere. Using this technique can either make your codes better or just make it a mess.

  5. Check compatibilities.

    In building applications, we use all kinds of tools and libraries. We need to understand that they don’t always match up together. A new version of a library might not work with the old version of another library that you’re using. You would need to read release notes or wikis of these tools and libraries so you would know if they are backwards compatible or if there are other steps that you need to make for older versions to work with it.

  6. Ask your real bestfriend.

    When after going through 1 – 5, your error is still lingering in your application, remember that you’re not alone. Your friends, colleagues, co-workers, or anyone in your network might have experienced the same thing. Post your questions in stackoverflow or in other forums. When you’re using a 3rd party library, try to reach out to the developers and ask them about what’s causing your bug. When you’ve already done your best, it’s never wrong to ask, most especially when you’re in a really tight deadline. J

  7. Be patient, take some rest, and go back to 1.

If you need help in any of your applications development projects, Web, Mobile and/or Salesforce.com, do feel free to contact our team. We are always happy to help!

Leave a Reply