HOME     >    >    >     TUTORIALS TABLE OF CONTENTS

Pascal tutorial: Debugging.. and avoiding the need

This has good information

Please don't dismiss it because it isn't full of graphics, scripts, cookies, etc!
This information should also help Delphi programmers.

Program creation:

You shouldn't need to debug your programs!! (So why is it that I always have to debug mine?) If a program is written in a disciplined, careful manner it won't need debugging. I make this perhaps obvious, perhaps sanctimonious observation to encourage you to AVOID "poke and hope" programming. Almost always, if I try to "fix" something with a little bit of something that hasn't been thought through carefully, I end up with a mess that takes longer to get working than if I'd just worked a little more deliberately in the first place.


Semicolons are NOT hard... but they do lead to problems.

In general: if in doubt, put one in! Also worth remembering: The Borland compilers will often point to an "error" in line, say 125, if you have made some mistake (such as a missed semicolon) in line 124.

Where you must NOT put a semicolon: IN FRONT of an "Else" (e.g. in an if..then..else.. block, or in a case.. of.. else.. block*)

(I'll try to expand this in due course)


Pascal is a very orderly language. The basis of that order is the "block".. a concept that rewards study.

When writing Pascal, sometimes it pays NOT to work "from left to right, top to bottom." Take a simple comment as an example. You could write it as follows...

(*This
(*This is a
(*This is a comment done
(*This is a comment done left to
(*This is a comment done left to right
(*This is a comment done left to right*)

What I'd recommend is that you do...

(**)
(*This*)
(*This is a*)
(*This is a comment done*)
(*This is a comment done "ends first" then middle*)

The difference? The terminating *) was done immediately after the opening (*, and the text of the comment was filled in after the structure for the comment was established.

Other common cases where I do the "ends" first, then the "guts":

Procedure or function declarations, e.g. I start with:
procedure DoSomething;
var
begin
end;

If.. then... structures:
if ShouldDoIt then begin
end (*no ; here*)
else begin
end;(*else of if ShouldDoIt..*)

(By the way, I almost always put the "(*no ; here*)" comment in if I have an end before an else. It is so easy (and fatal) to put on it in passing if you see a "naked" "end" in some code. I also frequently comment WHAT an end ends.*)

And lastly- almost trivial, but still useful:
The ' marks either side of a string. If I need sTmp:='Fred';, I hit two 's after the :=, hit the left arrow once, type Fred.


I promised to tell you not only how to debug, but also how to avoid the need. One aid to Producing Perfect Programs Promptly is using indents to elucidate the program's structure. There are no definitive rules for what is "correct", but I think the following illustrates some ideas which may be of use.
program Demo;
var sTmp:string;
    bFred:byte;
begin
repeat
  readln(sTmp)
  if length(sTmp)>1 then begin
    writeln('Please enter only one character');
    readln(sTmp);
    end;
  until length(sTmp)=1;
writeln('Here is a lot of them!'+sTmp+sTmp+sTmp+sTmp+sTmp+sTmp);end;


Many texts, by the way, would have you move the "until" out to the same column as its repeat. This is logical, but having the first row AFTER the end of the repeat block move left also has merits. The same discussion can be held concerning the column for the end for the begin on the "if" line. Do what makes sense to you... but have a plan, use it!


When you name variables, of course you will use meaningful names. For instance in a program to calculate the area of rectangles, you would have variables called Length and Width. If you have other lengths and widths in the program, it may make sense to call them RectLenth and RectWidth... but PREfixing both with "rect" they would appear near one another in an alphabetical list. While program exist to give you lists of the variables you are using, I must admit I've rarely used them... however, somehow, it still helps me to keep things clear to name things so that related variable's names would be near one another in a list. Many of my variable names are based on several words, and I jam them together, putting a capital where each word begins. This seems as good, but with less typing than a common alternative: Rect_length.

Another refinement of variable naming that is VERY worthwhile is, I believe, called Hungarian nomenclature. In this, every variable name is prefixed by something to indicate the type of the variable. In my source code, that part of the variable name is always in lower case ("small" letter), and the next part of the name starts with an upper case letter. I use b for byte type variables, s for string, li for long int, etc. Examples: bRectLength, sFileName

Most of my programs have a global bTmp (and maybe bTmp2, bTmp3, etc) and sTmp. The TeMPorary in their name tells me that the contents of these variables are guaranteed only over very short sections of code. If you don't see the value put into the variable, don't assume what it is going to be. Consequently, don't put something into a variable called bTmp if you want it still to be there any significant time later.


Turbo Pascal offers great debugging tools. Master them, soon. In the meantime, just putting things like...

writeln('The value in bMyVariable at the moment is:');
writeln(bMyVariable);
readln(sTmp);

... in your code will often open your eyes to what your program is REALLY doing. (As opposed to what you thought you told it to do!) Choosing the right spot to put the little message sender is an art you will master. (The fancy alternative is called a "breakpoint", and you'll want to master "stepping through" and "tracing into" your code... but the message sending system described above will help until then!) (If you were to put the above into a program, it would need to have sTmp declared as a string, and not needed for other things at the moment, and you'd have a variable of your own devising and declaring called bMyVariable in use.)



Ad from page's editor: Yes.. I do enjoy compiling these things for you... hope they are helpful. However... this doesn't pay my bills!!! If you find this stuff useful, (and you run an MS-DOS or Windows PC) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!
Click here to visit editor's freeware, shareware page.

Link to Tutorials main page
How to email or write this page's editor, Tom Boyd

- - o - -