Ask HN: How to prevent bugs in your code?

The short answer is: You can’t. But you can try.<p>Try doing the following to reduce bugs:<p>1.Write a lot of unit test cases covering all know scenarios that you have in your spec or mind. This only assures that there are no bugs in your set of test cases, however there could be bugs lying out side your test case set.<p>2.Before changing your code check if you have test cases written for the code. If not do step 1.<p>3.Have good logging for your code in action. If a bug is found later it will help you to root cause it.<p>4.If you are in object oriented programming try to replace if else codes with polymorphism. Its difficult but if you can it will either reduce logical bugs or help you find them quickly as they unfold.<p>5.Test for all if and else conditions. All if condition with complex logical arguments (using AND / OR) must be checked for all conditions.<p>6.Learn from your mistakes in coding and try not to repeat them.<p>That said, its easier said than done. I would follow this thread how other suggests and learn.

Well it's actually quite simple - the amount of bugs depends on the amount of code - less code, less bugs.<p>To truly eliminate bugs, you either need to be able to see the future or have learned from your mistakes and from others' mistakes. (The latter being more common)<p>Depending on what you're doing, chances are if there isn't a clear separation of concerns and you're not following good/best practices (ia. solid, grasp, design patterns, ddd/tdd/bdd/*design) and - proper planning - there will be bugs.<p>Another thing developers generally struggle with is calling something by its name, ex. var a = 13 vs. var age = 13. That generally confuses even the developer himself after he went to take a leak.<p>I also agree on all Samikcs points - in addition to that there is really a lot of different ways to 'test code' ea, integration testing, unit testing, behavioral testing, requirements testing, deployment testing etc. - even software testers have to attend courses/study.<p>If you've read up to here, you will have realised there is no one answer. Programming isn't a task to be taken light-heartedly. Plan. Develop. Test. Verify. Repeat.

Finding bugs: I'm a big believer in Linus' law - which basically says that the more people look at your code, the more likely you are to identify bugs.<p>In my experience, the single best way to identify bugs and other problems is to have a good code review process. Any at all is better than none. Code review can be frightening for the person whose code is being picked apart, but it is important to remember that it shouldn't be a personal thing. Even the best developers in the world write bugs - it's just the nature of the beast.<p>If you don't have a continuous integration process, think seriously about implementing one. It can be a pain in the arse to set up continuous integration after a project is already well under way, but do it anyway - because it will most likely save you a ton of time further down the road.

Pass the code around to group-think.<p>Test-Cases!<p>Pray to Buddha to bring you a pony and a plastic rocket.<p>'Read' your code. Start at the top, draw your way (manually) all the way down through each line, each decision structure, until you have reached the end. Then go back up and do it all again but with a slightly different path. (Not for large code segments; more just for smaller, components.)

Well, start with collecting statistics and see if there's a recurring theme in your bugs. You can't find a cure, if you don't know what the disease is.

1. Think carefully before you code.<p>2. Then you code.<p>3. Read what you just coded.<p>4. Peer review before/after you checked it in.