0% found this document useful (0 votes)
41 views

Debugging Tips

This document provides tips for debugging programs, including symptoms of common issues and ways to locate bugs. Some key points: 1) Common problems include rounding errors from integer calculations, uninitialized variables causing incorrect results, and improperly sized arrays. 2) Floating point numbers should not be tested for equality and absolute values may be needed in comparisons. Complex logical tests should be avoided. 3) Programs should be written piece by piece and each piece tested before moving on. Use implicit none and read data from files instead of user input when possible. Always check for division by zero.

Uploaded by

tufagirma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
41 views

Debugging Tips

This document provides tips for debugging programs, including symptoms of common issues and ways to locate bugs. Some key points: 1) Common problems include rounding errors from integer calculations, uninitialized variables causing incorrect results, and improperly sized arrays. 2) Floating point numbers should not be tested for equality and absolute values may be needed in comparisons. Complex logical tests should be avoided. 3) Programs should be written piece by piece and each piece tested before moving on. Use implicit none and read data from files instead of user input when possible. Always check for division by zero.

Uploaded by

tufagirma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

De-bugging Tips

Symptoms and probable causes

� Have you got rounding errors?


� Don’t do floating point calculations using integers

� Are your calculations completely wrong?


� Initialise all your variables – don’t forget arrays!
� Make sure your arrays are big enough to hold all the data.
� Check that arguments passed to subroutines agree exactly in size, type and
position

� Is the program’s logic working the way it should?


� You must not test floating point numbers for equality. Example:
if (x == 1) then
does not work.
� Should you be using the absolute value of a calculation? Example:
if (abs(x-y)<.00001) then
� Don’t have overly elaborate logical tests. It’s probably better to test one or two
things at a time rather than this sort of thing….
if (((x.AND.y).OR.z > 10).OR.(.NOT. xx < 0)) then …
you might think you understood it when you wrote it, but imagine trying to figure
out what’s happening if the program breaks!

Wise precautions and time saving tips


� Don't try and write a complicated program all at once. Write it a piece at a time
and check that each piece is working correctly before doing the next bit.
� Use ‘implicit none’ at the start of all programs and subroutines.
� If you program needs data to be entered by the user, you will save hours of time by
taking the trouble to read in the data from a file rather than have the user – ie you key
in the numbers. If you don’t want to read from a file then you can assign the numbers
directly in the program.
� Always do a test for ‘division by zero’ when dividing.
� BE NEAT! Good programming is like plain speaking – there’s no mileage in tricky,
difficult to read code.

How to find the bugs


Use a print statement to print out the values within the program – take a look at this code…
x = x + 1
z = x * y
print *, ‘debug statement 1 value of x ,y,z‘, x,y,z
do ii =1,10
z = x * ii
if (ii == 5) then
print *, ‘debug do loop value of z when I = 5’ ,z
end if
end do
if (z>2000) then
print *, ‘debug statement – z>2000 value of z ‘,z
stop
end if

Notice how we can print out values of specific variables, stopping the program if necessary.

G1BNCM 42 Spring 2007

You might also like