1. An Introduction to Debugging
CPS120
Introduction to Computer Science

2. Compiling and Debugging
Executable code will not be created until you correct all of the syntax errors in your source code

3. Syntax & Logic Errors
A syntax error is simply the violation of the rules of a language; misuse of structure and form in programming or a violation of the compiler’s rules. These errors are detected by the compiler
Also know as 'fatal compilation errors'
A logic error is a mistake that complies with the rules of the compiler that causes the program to generate incorrect output

4. Linker Errors Not all syntax errors are detectable by the compiler
These errors do not become apparent until files are put together to create an executable
These errors are not linked to a specific line of code
Look for the name of the variable and see what lines of code it occurs on using EDIT and FIND
LNIK2001: unresolved external
LNK1120: unresolved externals
The equivalent of the use of to, two and too in English.

5. Debugging
Debugging is the process of locating and fixing or bypassing bugs (errors) in computer program code or the engineering of a hardware device.
To debug a program or hardware device is to start with a problem, isolate the source of the problem, and then fix it.

6. Debugging Objective
Find the line(s) containing the syntax error(s) using the compiler's chosen line and error messages as a starting point

7. Debugging is an Art
Compilers often miss reporting an actual error and report on subsequent lines which are effected by error but may be completely correct
After encountering a real syntax error, compilers often generate many incorrect syntax error messages
Different compilers produce different errors and warnings for the same errors in the same program

8. Debugging Steps Proofread before compiling Compile
Correct all the obvious errors
Start at the beginning of the list of errors and warnings
A single syntax error may cause the compiler to believe numerous other syntax errors are occurring
Look at the error lines and if you see the error, fix it. Otherwise, leave it for later. It may vanish when you fix something else
Don’t worry if more errors appear. Some errors mask other errors

9. Debugging Steps Recompile when you have fixed what you recognize
Repeat 3 & 4 until no further errors are obvious
Attempt to solve the remaining errors in a top-down fashion
Solve whatever errors you can without spending long periods of time on any given error
Recompile whenever you feel you don’t see any further solutions

10. Debugging Aids
In the Visual C++ (and other GUI-based compilers) double-clicking on an error message move the cursor to the line where the compiler detected the error
This may not be the actual line where the error occurred – don’t trust the compiler on lines
Work from the beginning of the program, because in most compilers, the errors are detected from the beginning to end, sequentially
Some errors are so severe, they stop the compiler from continuing so more errors may appear after you successfully fix one or more

11. A Debugging Mindset Assume your syntax is wrong. Look it up!
Add working comments as you change things
If you are 100% sure a line is correct, then search for a syntax error in the lines ABOVE that line
Start with the immediately previous line and work backward
Never make a change you can’t explain

12. Sample Debugging Comment
cuot << "This is a line of code"<< endl;
/*************Debug*************
Error is undeclared identifier
Checked syntax for endl
Check syntax for screen output
-- cuot is misspelled */

13. Debugging Checklist
Visually verify the spelling and case of keywords and identifiers
-- Remember, in the editor, keywords are blue, literals are black and comments are green
-- Look for problems with l and 1 and o and 0
Verify syntax with a reference book, not just visually
-- Don’t trust your eyes; you see what is supposed to be there
Try to find an example in the reference book that does something similar and compare the code
Verify that the necessary delimiters used for that line are there
-- Check the lines above and below as well

14. Debugging Checklist
Without looking at your source code or notes, rewrite the instruction on a piece of paper and then compare it to your actual code; don’t cheat
Verify that the line is really the source of the error by commenting the line using //
Don’t worry about other errors that result from this
If the error disappears, it probably results from the line you are working on
If it moves to the next line it is probably caused earlier in the code
Remember that the compiler cannot be trusted to pinpoint lines

15. Warnings
Actions that may represent problems but do not cause the compiler to flag an error
Don’t ignore warnings
Most common warning is a ‘typecasting’ warning
Indicates that the conversion of one type of a number was moved to a number (variable) of a different type without inclusion of a typecasting operation
E.G. – Moving a float to an integer variable

16. Common Causes for Warnings
An equal sign used in an expression is actually an assignment operator, not the relational operator testing for equality
Loops where one condition could never logically be executed
Testing a variable that has not received a value yet

17. Disk Space Issues
If the floppy is full or becomes full during the compilation process, the compile will fail with an error message such as:
fatal error C1033: cannot open program database
A very cryptic message like this can result
If you are not able to view all of the intermediate files created in a compile, suspect a space error

18. Semantic Error Detection
Use the tracing method to display the value of critical variables
Make the error reproducible
Get a stack trace of function calls to verify sequencing
Correct the error immediately when you find it and check if you made it somewhere else
Examine your last code changes for errors
Ensure that you have saved and run the corrected programs

19. Error Prevention & Testing
Use good design and programming style
Don't use global variables
Study your code before typing and running it
Have someone else look at it
Make your program self-documented
Program defensively – put in assertions and self-checking code and comment them out
Test your code at boundary values for variables
Log your bugs
Test code in pieces using "stubs"
Consider – correctness, reliability, utility and performance