Everyone hates bugs. They make your program not work how you want it to, and just might trigger you to stick a sharp pointy object into your computer during debugging. Seriously, though, debugging a program is no fun. However, there are a few ways to get around the simple mistakes that might make debugging less of a pain.
Types of bugs
There are a few general categories of bugs. By knowing what kind of bug you have will provide a huge leap towards fixing the problem.
This simply means that the compiler can't compile the code. This is usually the result of a typo or trying to do something not allowed by the compiler.
loop: djnx loop ;as opposed to djnz loop ld a,hl ; illegal instruction jr label ; No definition of label in program
These are usually the easiest bugs to fix. All that it requires usually is a simple change in lettering to make the compiler happy.
These are errors that you may experience when you actually run the program. An example for higher-level programming is trying to divide by 0.
push hl ret ;returned to pushed hl value, not last value of program counter ld hl,label jr label ;accidentally jumped to a variable instead of actual code label: .db $FF
Please note that while your calculator may run into run-time errors, it will not throw any error messages unless you implement them into the code. The normal course of action usually a crash, followed by a ram reset.
The most difficult of all errors to fix are logic errors. Logic errors are those that compile and run correctly, but don't give you the results that you want.
; trying to multiply by 4 ld a,6 add a,a add a,b ; oops, accidentally added the wrong values together
The reason logic errors are so difficult to fix is that they are very hard to detect, and even though you may be able to narrow down the section of code that is causing the problem, you still have to go through that section one line at a time to find the reason for the error.
Trying to find error all by yourself is an extremely tough position. Instead, you can invite your friends, family, etc. to help. Give them the program and have them test it out. If they run into any errors, they can tell you the problem, and will make your job that much easier.
Now that we have the major bugs out of the program, it's time to move forward with releasing your program. Note that writing a working program is only part of the project, there are still other parts that need to be addressed.