Bug Free Programming

Bug Free Programming

The trick to bug free programming is a rock solid understanding of the code you write.

http://programmers.stackexchange.com/questions/41248/how-to-be-a-zero-bug-programmer

• Be humble -- you are and will be making mistakes. Repeatedly.
• Be fully aware of the limited size of your skull. Approach task with full humility, and avoid clever tricks like the plague. [Edsger Dijkstra]
• Fight combinatorial explosion
• Get rid of mutable state (where ever possible). Yes, learn functional programming.
• Reduce number of possible code paths
• Understand (the magnitude of) the size of the input & output spaces (of your functions), and try to reduce them in order to get ever closer to 100% test coverage
• Always assume your code is not working -- prove it otherwise!

• Write less and write smarter. Less code is typically better code. It's natural to want to plan ahead and try to make awesome design patterns but in the long run just writing what you need saves time and prevents bugs.
• Complexity is the enemy. Less does not count if it's an obscure complicated mess. Code golf is fun but it is hell to understand and a worse hell to debug. Whenever you write complicated code you open your self up to a world of problems. Keep things simple and short.
• Complexity is subjective. Code that was once complicated becomes simple once you become a better programmer.
• Experience matters. One of the two ways to become a better programmer is to practice. Practice is NOT writing programs you know how to write with ease, it's writing programs that hurt a little and make you think.
• The other way to get better is to read. There are a lot of hard topics in programming to learn but you'll never be able to learn them by just programming, you need to study them. You need to read the hard stuff. Things like security and concurrency are impossible it learn correctly from just writing code unless you want to learn by cleaning up disasters. If you don't believe me look at the epic security issues sites like gawker had. If they took the time to learn how to do security correctly and not just make something that worked that mess would never have happened.
• Read blogs. There are a ton of interesting blogs out there that will give you new and interesting ways to look at and think about programming this will help you to...
• Learn the dirty details. The minor details of how obscure parts of your language and application work are very important. They could hold secrets that help you avoid writing complicated code or could be parts that have there own bugs you need to avoid.
• Learn how the users think. Sometimes your users are flat out insane and will work with your app in ways you don't understand and can't predict. You need to get in to their heads enough to know the stranger things they might try and make sure your app can handle it.

• Developers suck at testing. It's true and you know it. (I'm a developer!) A good QA team will always find the edge cases that developers never think about.
• Developers are good at coding. Let them get back to what they excel at (and usually what they prefer to do anyway.)
• The QA team can find bugs related to multiple developer tasks in one pass.

Keeping the code as simple as you can will help you to avoid bugs.

Use libraries extensively; the probably have been debugged better.

Bugs are not acceptable, and I will do everything within my power to eliminate them.

Program defensively: http://en.wikipedia.org/wiki/Defensive_programming

http://www.yegor256.com/2015/06/18/good-programmers-bug-free.html
?????
good programmers prefer to make functionality buggy and incomplete while keeping the design clean and easy to maintain. 
http://www.yacoset.com/Home/how-to-avoid-writing-bugs

 There is a theory to writing bug-free code (or rather, bug-minimal), and each technique that applies it combines the same two ingredients in different ways:

1. Reason about the code explicitly by writing more code
2. Test the assumptions and outcomes by writing more code

http://www.yegor256.com/2015/06/18/good-programmers-bug-free.html
Good programmers make cheaper mistakes in order to avoid making more expensive ones
http://stackoverflow.com/questions/115528/how-to-make-a-program-bug-free-or-with-the-less-possible-bugs

Testing

• Test-driven development
• Unit testing
• Automated testing
• Functionnality testing
• Mutation testing
• Test by a team and bypassers

Tools

• Source control
• Good editor / IDE
• Bugtracking software
• Static code analysis

Practices, management, environment

• Code coverage
• Peer code review
• Assertions to check assumptions
• Continuous integration
• Development stages
• No distractions while working
• Time

https://www.getdonedone.com/five-test-cases-for-fewer-bugs/

• More test coverage.
• More code reviews.
• More QA time.
• More architecture.

When you’ve coded up something new, ask yourself these five questions, and test for them!

• What happens if something is null?
• What happens if there are zero of something?
• What happens if there is one of something?
• What happens if there are three of something?
• What happens if there are a lot of something?

Consider all of these cases, all of the time. 

https://www.quora.com/How-do-I-train-myself-to-code-faster-and-with-fewer-bugs
Find Your Weak Spots
Corner Cases
Do not release products with known corner-cases; 

Practice

you need to always be aware of the mistakes you're making and what techniques you apply to fix them.Awareness

Whenever you discover a bug ask yourself:

• Why did I make it in the first place?
• What can I do in the future to avoid making this type of bug again?
• How can I write my code in a way such that even if I repeat this bug, it will be easier to spot and fix? (think: coding style, modularization, separation of concerns)

Log every bug and the answers to these questions in a programming journal. After a while you will notice patterns and you can learn how to avoid making the same mistakes over and over again. If you are not aware of what mistakes you're making, you can't possibly know what to avoid.

Bugs come in a few varieties:

1. Slip of the fingers.
   
   Perhaps you meant to type a '+' when you hit the '-' key. Or you forgot to add a parameter to a function/method call, and it went with its default parameter. Or maybe tripped over an even more subtle nuance of the language you are using.
    
2. Trying out new programming constructs or patterns.
   
   If you are trying some new construct, you might want to play around with it first in test code before you put it in production code.

• Learn to not use either a debugger or debugging output statements to find bugs. Find bugs by reading the code carefully.
• • Clever code should be avoided until you have many years of experience under your belt.
  • Develop a consistent style for naming variables, stick to it across projects and even languages.
  • Code carefully, do not rely on the compiler to catch syntax errors. You already get great help from most IDEs. When you become an experienced programmer, once in a while, you can type out a large amount of code that compiles and runs perfectly in one shot and passes all tests. This is what you should aim for.