Teaching Programming IV

Address Book

When you start programming, you concentrate on the use of programming statements, in order to achieve the results you desire. This is inevitable, but it means that you are concentrating on only one half of what programming is really all about. A substantial program is made up of two elements, instructions and data. When designing a program it is deciding how you are going to represent the real-life data that often gives you the most trouble.

For non-trivial programs, you can say that:

Programs = Algorithms + Data Structures

The theoretical study of data structures has been started before this part of the practical course is introduced.

A data structure is an organised collection of atomic data items. An array or a linked list are examples of data structures. A string is also a data structure, since it is an organised collection of characters. Turbo Pascal has a string data type, which is used in a similar way to the other atomic types (integer, char, etc.), so this point has to be emphasised carefully, to avoid confusion. Arrays and linked lists can be used to implement other more specialised data structures, such as stacks and queues, but it is up to you to program them so that they behave properly (eg. with a queue, new items can only join at the back of the queue and items can only leave in order, from the front).

This exercise gets the students to create a simple address book, using arrays. One array is used for the names, another for the addresses and a third one for the telephone numbers. The following techniques will be introduced:

Use of a menu structure (I get my students to use a general menu function that I have programmed, to remove the need to program their own. It is much more complex than anything they could program at this stage and it teaches them to make good use of existing libraries. However, you could get them to produce a simple menu of their own)
Using arrays and working with indexes
Editing data (use of appropriate algorithmic structures to allow as much flexibility as possible, validation, user prompts, etc)
Displaying data on screen, record by record and also, a page at a time
Saving data in a text file
Loading data from a text file
Use of comments. As this is their first substantial program, this is the point at which I choose to emphasise the need for and the use of comments.

When writing new programs, students should be encouraged to program data entry first, followed by saving and loading. This allows some trial data to be entered and saved early on, which can then be used to test the other features as they are written. Some students waste a great deal of time, constantly entering the same test data, over and over again, because their program is unable to save anything.

When editing, students should be encouraged to implement algorithmic structures that allow the user to stop editing at any point, without having to go through every single field in a record, for example. The better ones could be encouraged to enter data into dummy variables and to copy them into the main data structures when editing is completed and the changes are accepted. This allows an ABANDON option to be offered, which leaves the main data structures unchanged.

Those who finish ahead of the class can be got to program record selection using a moving cursor, or by highlighting the appropriate record, instead of by entering the record number via the keyboard.

Baker's Programming Continuum

This is a piece of classroom nonsense, that I would not normally bother to mention. I first used it as a light-hearted aside, however it seemed to have a very positive effect and I have been using it ever since!

Groups seem to reach a stage, usually around 4-5 months into the course, when you start to get lots of long, silly error messages and unnecessary embelishments. Some of the students are starting to think that they are pretty good programmers. This usually happens around the time that they are working on their first "useful" program, which is normally the address book. It is time to bring them back down to earth, so I show them my Programming Continuum diagram, explaining that the exercises that we started off with, such as writing their name on the screen 5 times, come into the "Really Naff" category. I then point out where I think their programs lie on it (usually well over to the left!).

I then explain why their programs are still less than useful and this usually develops into a very positive discussion, on what constitutes a useful program (useful processing of data, data storage, comprehesive validation, etc.), the need to do as much work as possible for the user, the need for good, concise communication with the user, and so on. We also examine what characterises professional programs. What makes this such a useful exercise is that by this stage the students are starting to acquire the skills that allow them to produce much higher quality work, but being funny or finishing each exercise as quickly as possible is often the main aim! This focuses their attention on the quality of their work and seems to motivate them to make the additional effort required.

Pupil Records

This exercise gets the students to program a simple database. It builds on the skills first introduced with the address book (use of menus, data entry and editing, loading and saving, etc.) and introduces these elements:

The record structure. Instead of using several arrays, students have to use an array of records for this exercise.
Searching. They have to implement a facility which allows a search to be carried out on at least one field. A sequential search is acceptable, the better students might come back to implement a binary search later.
Sorting. The selection sort is probably the easiest to program. The students are asked to produce a database that can sort on at least one field.

Noughts and Crosses

In recent years, I have not got beyond the pupil database program. However, if time allows, or you have one or more particularly able programmers, this makes a good exercise to end the year on. The students have to implement a noughts and crosses playing board, for two human players (trying to get the computer to act as one player would be a good challenge for anyone who shows interest!). The players input their moves in turn and these are recorded on screen. The computer only allows legal moves and detects when a game has finished. This is perhaps more of a modelling exercise than any of the others, and shows a use for a two-dimensional array. It calls for careful thought about validation and knowing when a game has ended. It does not call for a huge program, but requries some quality thought and is a useful extension exercise.

Return to Contents

Teaching Programming I
Teaching Programming II
Teaching Programming III

Author: Mark Baker, e-mail mbaker@rmplc.co.uk
Last revision: 4th January 1997