Towards bug free code:

The only way to have bug-free code is to mathematically prove the code. Very few programs in the world are mathematically proved. Some industry can afford the price of a mathematical proof, especially when bugs would turn into human death, such as embedded software in planes, trains or cars. Most of us are working on projects that cannot afford the cost of a mathematical proof. We then rely on some tricks to maintain our bug rate as low as possible. We can classify these tricks into 6 categories.

Contract
Automatic test
Empirical approach
Code review
Prioritizing bugs fix over new features development
Programming style and code quality
Static Analysis Tools

Contract - The idea of contracts is to insert correctness information inside the code. When contract is violated it means that your code contains a bug somewhere.

Automatic Test - The important thing to remember is that having a solid battery of automatic tests is an excellent way to decrease significantly the bug rate on tested code, but also to avoid new bugs when code gets refactored.

Empirical Approach - empirical approach is a simple tenet that every seasoned programmer knows:
Most of bugs in a new version are coming from modified code and brand new code
Unchanged code that works well for a long time in production won't likely crash within the next release (what we call stable code). We don't say that stable code don't contain bug, but discovering a bug in stable code is rare.
Code Review - Code reviews are good to enhance quality and to educate programmers. Focus your review on not stable code, i.e added code and modified code. If you release new versions often, the mass of code to review before each release will quickly become an epsilon of the size of your entire code base.

Prioritizing bugs fix over new features development - This popular methodology directly results from the concept of stable code. Prioritizing bugs fix over new features development can be seen as a way to constantly struggle to maximize the surface of stable code in our code base.
Programming Style and Code Quality - Object style programming is more bug-prone than functional style programming. This fact results from the expressiveness of functional style. In other words, functional code is easier to read and understand. Code quality has also a direct impact on code correctness. Anti pattern such as methods with high LOC, high Cyclomatic Complexity or high Nesting Depth, entangled components, methods with multiple concerns, classes with multiple responsibilities… leads to code harder to debug and to test.

Static Analysis Tool - Some tools are already able to detect naïve mistakes. But most bugs are not that easy to pinpoint. By just analyzing the code a tool cannot distinguish between a feature and a bug because it doesn’t know how the application should behave.

Conclusion:
Having a bug-free product to release shouldn’t be the goal. Anyway, every program not mathematically proved has bugs. The goal should then be to tend toward a bug-free product by applying as many correctness tricks as possible.