VCE SD Theory Slideshows

By Mark KellyVceit.com

DebuggingTechniques

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 code’s 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 it’s 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 code’s workings• Don’t 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 can’t 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 <, = and > boundary

value (e.g. 17,18,19)

By Mark Kellymark@vceit.com

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