Code rarely works as intended at the first time of asking. This is completely normal and something that even professional software engineers deal with on a daily basis. Just think of all the software updates released by Apple and Microsoft etc. These are to fix errors and mistakes made by their software engineers!
I do not like referring to these errors as 'bugs'. It can give the impression that it is somehow not your fault and it is just an unlucky occurrence. Wrong! If YOUR code does not work as expected, it is because YOU have made a mistake and it is YOUR responsibility to find and fix it! Companies do not employ a team of de-buggers to go around and fix the errors made by the software engineering!
'De-bugging' is just as big a part of software development as is writing the code itself. If you have made a mistake and your first instinct is to put your hand up and expect the teacher or lab helper to find and fix it for you, you will never learn how to 'de-bug' and by extension, never learn how to program!
I have seen this first-hand with many students over many years. The students who never improve and graduate without being able to program are usually the ones who asked for help every 15 minutes in the lab sessions. Typically every lab session, in every module, in every year of study. Why is it that they got more one-to-one support and help then others but still needed more help 15 minutes later? It is because they have never learned how to 'de-bug' as they always relied on someone else to do it for them!
'De-bugging' can be frustrating and painful. Trust me, I have spent months of my life finding and fixing errors in code I have written! Although at the time it may seem like a waste of time, it is crucial when it comes to building experience and learning from your mistakes. It takes patience, determination and resilience. These are inherent parts of your personality that a teacher cannot give you! If you lack any of these positive characteristics, you simply cannot expect someone else to keep coming and digging you out of a hole. With that kind of attitude, you will not succeed as an engineer! Be honest, would you employ someone like that?
There are some things you can do to reduce the likelihood of making errors. One to is properly style and structure your code. Indenting makes it easier to see how the code is structured and can help to avoid making simple mistakes (that may take a long time to find and fix). Another is to write comments to remind yourself what you were trying to do when you wrote the code. Also, regularly compiling will help to catch simple syntax mistakes that prevent code from compiling (these errors can be classed as 'compile-time' bugs).
Compile-time (syntax) bugs are generally easy to fix as the compiler usually tells you the file and line number on which the error has occurred. It is then usually fairly simple to spot syntax mistakes such as missing closing brackets or semi-colons. Even if the code does compile, there is no saying that it will work as intended. Finding the bugs that prevent the code from working properly is much more difficult. These can be classed as 'run-time' bugs as they occur during the code running. In this lab, we will look at a couple of methods that can be used to assist during de-bugging at run-time.