VCE SD Theory Slideshows By Mark Kelly Vceit.com Debugging Techniques

Contents Origin Why debug? Techniques Test data IN PROGRESS 6 Feb 2012…

The original debugging Often said to have begun with Admiral Grace Hopper in the 1940s. While she was working on a Mark II Computer at Harvard University, her associates discovered a moth stuck in a relay which stopped it working. Removing the moth amounted to "debugging" the system.

The first bug

But, to ruin a good story The use of bug for a system fault had been since the days of Thomas Edison.

What is debugging? The process of finding and fixing errors in programming. Error types: – Syntax errors – Logical errors – Runtime errors

Syntax errors When the source (human-readable) code is not presented in a format that the compiler or interpreter can understand For example: – PRONT Hello (mistyped keyword) – PRINT Hello (punctuation error) – RND(0) instead of RAND(0) or RANDOM (wrong keyword)

Syntax Errors Very easy for a compiler/interpreter to find and tell you about Usually easy for you to fix

Logical Errors The source codes format and punctuation is correct, but it does not produce the expected answer Usually a fault of the algorithm – the method of calculation Since no warnings appear, logical errors go undetected without extensive testing

Logical errors E.g. Wanting to increase a number by 10% Using this: X = X + 10% Actually adds 0.1 to X. Needed X = X + (X*10%)

Runtime errors Syntax is perfect Logic is correct Something bad occurs during execution, e.g. – Lost network connectivity – Jammed printer – Running out of memory or disk space – Operating system failure

Analogy Syntax error: trying to board a bus through the exhaust pipe Logical error: getting on the wrong bus Runtime error: the bus breaks down

Debugging Techniques Use modular programming (more later) to reduce the amount of code you have to wade through. Inspect the values of variables line by line until the fault appears (e.g. DEBUG PRINT Value is & X Set breakpoints to pause execution and let you inspect values

Debugging tools Different IDEs (integrated development environments) offer different debugging tools – Dedicated external debugger – Breakpoints – Single-stepping – Immediate window for inspecting values – Step into/over code – Compiler reports

Debug Reduce the amount of active code remming out code (converting it to comments) to isolate the faulty code. Use MSGBOX statements to show program flow (which parts of code are being executed). You might assume a module or branch of an IF statement is executing whereas its not even getting that far. Use DEBUG PRINT to show values during execution

Debugging Look for patterns. Code often includes similar lines but one might be subtly different which highlights the error. Use code indenting so missing or misplaced parts of structures, loops etc are highlighted. Be persistent and logical and detailed. Code walk-through (desk-checking) line by line

Assert Programmers tend to assume incoming values are right (e.g. a positive integer) Assert is debugging code (removed during compilation) that checks these assumptions are true For example…

Asserting yourself Function myFunction (x as Long, y as Long Debug.Assert (x<>0 And y<>0) myFunction = 1/x + 1/y End Function If it turns out that X=0 or Y=0, the DEBUG.ASSERT statement turns out to be false, and it warns you that your assumptions about X and/or Y are false. If the DEBUG.ASSERT statement is true, execution proceeds normally.

Preventative measures Initialise variables explicitly Use meaningful variable names Use plenty of useful internal documentation to explain the codes workings Dont just assume values or parameters are correct when they arrive. Test them. Treat objects and properties carefully according to their type.

Algorithms Compare Google Page Rank algorithm with the inaccurate algorithms used before it Compare shell sort algorithm with bubble sort Compare searching with hash codes with a line-by-line search Compare sorting with an index and sorting by swapping values in an array.

Test data Used to test code Deliberately designed to expose faults or weaknesses in code Contains typical, unusual and bad data to test software behaviour and reactions Should test all possible data ranges

Boundary Conditions Most logical errors happen here At a boundary, program behaviour should change, e.g. if less than 18, you cant drink But equal to and over 18, can drink Be careful with =, > Many logical errors in exams are like this Test data should test for boundary value (e.g. 17,18,19)

By Mark Kelly These slideshows may be freely used, modified or distributed by teachers and students anywhere on the planet (but not elsewhere). They may NOT be sold. They must NOT be redistributed if you modify them. VCE IT THEORY SLIDESHOWS