Would you like to receive similar articles straight to your inbox?

8 ways to reduce bugs while coding

There was an interesting discussion at one of our internal mailing lists on how to reduce the number of bugs while coding. I am going to summarize the discussion here. Some of the points that were mentioned.

  • Write unit tests & integration tests for your module. Follow the principle of Test-Code-Test, write happy / failure test cases which would help you identify all possible inputs to your function and accordingly handle it.
  • Use Tools: Findbugs uses static analysis to find bugs in Java code, GetExceptional tracks errors in Ruby apps and reports them, Selenium helps you to easily check if the web elements are in place in different browsers and many more. It’s good to use these tools which make your life easy.
  • Compiler warnings: Don’t ignore compiler warnings. Often, they easily help you identify the bug in your code. Before you start debugging, compile your code once with the highest warning level and see if there are some obvious errors.
  • Code Review: Get your peers to look at your code before pushing it to production environment. Code reviews should be taken as a challenge to find out bugs in the other person’s code.
  • Logs: Loggers like log4j are easy to setup. Split the type of action into 3 types – error, warning and info and ensure you log a good amount of actions in your code, you should be easily able to trace what has happened by looking at the log file.
  • Use existing libraries: Don’t reinvent the wheel. If there is a well tested library that does the same function you were planning to code, use it! The library is used by many developers and it should have been a well tested one.
  • Pseudo code: It’s always better to write a pseudo-code of what you are planning to do before you start coding the module.
  • Avoid distractions: Distraction is the number one enemy for buggy code – a GTalk ping / twitter update can disturb your thought process. Use techniques like Pomodoro and tools like RescueTime to stay focused.

Happy Programming!

Image Courtesy:Flickr

Comments (25)

  • Do not “log a good amount of action” in your code. This is code duplication of a cross-cutting concern and would make the authors of The Pragmatic Programmer wince. Use Aspect Oriented Programming to inject logging into your application at compile-time from a single source. No duplication, no maintenance hassle, and switching loggers (for whatever reason) will be painless.

  • I’d like to add that smoking pot and/or drinking less-than-top-shelf scotch is a common cause of preventable coding errors.

  • Dave’s right, btw but logging is always a slowdown. And where’s your motivation as a programmer if the f8ckr doesn’t burn to the ground on launch day leaving no reasonable explanation?

  • Thats awesome, this will help each and every developer a lot while coding.
    Vivek [Founder of DeveloperSnippets – http://www.developersnippets.com]

  • How will writing pseudo code reduce the number of bugs?

    • martin
    • October 21, 2010 at 12:04 pm
    • Reply
  • There’s no faster way to lower morale than with code reviews.
    If you have to have them, at the very least, they should be presented as an opportunity to learn from each others code, not as a challenge to find problems.

  • @martin Writing pseudo-code helps you in understanding the overall flow of the module and identify possible edge cases beforehand prior to start programming
    @Matthew Agree to your points. But code reviews are viewed as boring, dull things and usually occupies the last spot in TODO list. This was just to bring it to first

    • Interviewstreet
    • October 21, 2010 at 4:15 pm
    • Reply
  • Thanks for the tips and suggested tools. Selenium in particular is exceptionally handy.

    • Ervin
    • October 21, 2010 at 6:03 pm
    • Reply
  • What is the name of the owner of this post?

  • @Ahmet It’s composed by Interviewstreet team

    • Interviewstreet
    • October 22, 2010 at 4:58 am
    • Reply
  • Writing pseudo-code helps you in understanding the overall flow of the module and identify possible edge cases beforehand prior to start programming
    Why will writing pseudo code help better with that than writing real code top down in a (fairly) high level programming language like Java or C#?

    • martin
    • October 22, 2010 at 8:52 am
    • Reply
    Programming is hard.
    You’ll never have finished learning programming, so learn to enjoy learning.
    ==> writing.bryanwoods4e.com/1-poor-poor-child
    ‘nuf said!

    • Keith Cromm
    • October 22, 2010 at 12:39 pm
    • Reply
  • I do not think writing in pseudo code is needed. What is needed is to know what you want to do. It can be in a drawing, a piece of paper, pseudo code, or throw away code.
    My workflow, when I have time:
    1. Decide what I want to do. This will tell me the course to follow.
    2. Gather all the information I need.
    3. Draw the flow in a piece of paper, without too many details. This will allow me to make a sensible schedule on what is yet to be done.
    4. Create the comments, structures and functions headers. I do this first, because I got fresh the idea of what I want to do and how to do it.
    5. Create dummy functions and create the program flow.
    6. Implement real functions with full debugging helpers, like logs, assertions etc.
    7. Debug it function by function to make sure everything is ok. Throw away code may work on this.
    8. Optimize and go back to 7, until I am happy with the results.
    9. Beta test and go back to 7, until all bugs that I didn’t catch are out.
    10. Ship. And archive. Knowing that the program is doing what it was supposed to do.

    • rxantos
    • October 23, 2010 at 8:38 pm
    • Reply

Leave a Reply

Your email address will not be published. Required fields are marked *