CMP 202- COMPUTER PROGRAMMING

II
LECTURE SERIES
OVERVIEW OF THE COURSE OUTLINE
Principles of Good programming
Structured programming concepts
Errors and Debugging
Testing
Text Files and IO
Structured Programming Concepts
• The concept of structured programming started in the late 1960’s
with an article by Edsger Dijkstra.
• He proposed a “go to less” method of planning programming logic
that eliminated the need for the branching category of control
structures.
• The topic was debated for about 20 years.
• But ultimately – “By the end of the 20th century nearly all computer
scientists were convinced that it is useful to learn and apply the
concepts of structured programming.”
What is Structured Programming?
• Structured programming is a programming paradigm aimed at
improving the clarity, quality, and development time of a computer
program
• By making extensive use of the structured control flow constructs of

• selection (if/then/else) and

• repetition (while and for),
• block structures, and
• subroutines
• In contrast to using simple tests and jumps such as the go to
statement, which can lead to “spaghetti code” that is potentially
difficult to follow and maintain.
• One of the most important concepts of programming is the ability to
control a program so that different lines of code are executed or that
some lines of code are executed many times.
• The mechanisms that allow us to control the flow of execution are
called control structures.
• Flowcharting is a method of documenting (charting) the flow (or
paths) that a program would execute.
• There are three main categories of control structures:
• Sequence – Very boring. Simply do one instruction then the next and the
next. Just do them in a given sequence or in the order listed. Most lines of
code are this.
 • Selection – This is where you select or choose between two or more flows.
The choice is decided by asking some sort of question. The answer
determines the path (or which lines of code) will be executed.
• Iteration – Also known as repetition, it allows some code (one to many lines)
to be executed (or repeated) several times. The code might not be executed
at all (repeat it zero times), executed a fixed number of times or executed
indefinitely until some condition has been met. Also known as looping
because the flowcharting shows the flow looping back to repeat the task.
• A fourth category describes unstructured code.
• Branching – An uncontrolled structure that allows the flow of execution to
jump to a different part of the program. This category is rarely used in
modular structured programming.
• All high-level programming languages have control structures. All languages have
the first three categories of control structures (sequence, selection, and
iteration). Most have the if then else structure (which belongs to the selection
category) and the while structure (which belongs to the iteration category). After
these two basic structures, there are usually language variations.
• In structured programming, we sub-divide the whole program into small modules
so that the program becomes easy to understand. The purpose of structured
programming is to linearize control flow through a computer program so that the
execution sequence follows the sequence in which the code is written.
• The dynamic structure of the program than resemble the static structure of the
program.
• This enhances the readability, testability, and modifiability of the program. This linear flow of
control can be managed by restricting the set of allowed applications construct to a single
entry, single exit formats.
Why we use Structured Programming?
• We use structured programming because it allows the programmer to
understand the program easily.
• If a program consists of thousands of instructions and an error occurs
then it is complicated to find that error in the whole program, but in
structured programming, we can easily detect the error and then go
to that location and correct it.
• This saves a lot of time.

• The following are rules in structured programming:

 Structured Rule One: Code Block
• If the entry conditions are correct, but the exit conditions are wrong, the
error must be in the block.
• This is not true if the execution is allowed to jump into a block. The error
might be anywhere in the program. Debugging under these circumstances is
much harder.
• A code block is structured, as shown in the figure. In flow-charting condition,
a box with a single entry point and single exit point are structured. Structured
programming is a method of making it evident that the program is correct.
Structure Rule Two: Sequence

• A sequence of blocks is correct if the exit conditions of each block

match the entry conditions of the following block.
• Execution enters each block at the block's entry point and leaves through the
block's exit point.
• The whole series can be regarded as a single block, with an entry point and an
exit point.
• Two or more code blocks in the sequence are structured, as shown in
the figure.
Structured Rule Three: Alternation

• If-then-else is frequently called alternation (because there are

alternative options).
• In structured programming, each choice is a code block.
• If alternation is organized as in the flowchart at right, then there is one entry
point (at the top) and one exit point (at the bottom).
• The structure should be coded so that if the entry conditions are fulfilled,
then the exit conditions are satisfied (just like a code block).
• The alternation of two code blocks is structured, as shown in the
figure.
Structured Rule 4: Iteration
• Iteration (while-loop) is organized as at right. It also has one entry
point and one exit point.
• The entry point has conditions that must be satisfied, and the exit
point has requirements that will be fulfilled.
• There are no jumps into the form from external points of the code.
• The iteration of a code block is structured, as shown in the figure.
Structured Rule 5: Nested Structures
• In flowcharting conditions, any code block can be spread into any of
the structures.
• If there is a portion of the flowchart that has a single entry point and
a single exit point, it can be summarized as a single code block.
• A structure (of any size) that has a single entry point and a single exit
point is equivalent to a code block.
• For example, we are designing a program to go through a list of
signed integers calculating the absolute value of each one.
• We may
• (1) first regard the program as one block, then
• (2) sketch in the iteration required, and finally
• (3) put in the details of the loop body, as shown in the figure.
------ Structured Rule 5: Nested Structures

• The other control structures are the case, do-until, do-while, and for
are not needed. However, they are sometimes convenient and are
usually regarded as part of structured programming. In assembly
language, they add little convenience.
Steps in a Programming Project
• In CMP201, the importance of a clear, structured programming style
has been emphasized. Because of the importance of these principles,
we will dive much into this concepts as it is worth reviewing them
here before we continue with the main part of CMP202.
• Any programming project, no matter how simple, should be divided
into several main sections:
1. Make sure you understand the problem you are trying to solve. This
may seem obvious, but many later problems in coding can be traced
back to your lack of a complete understanding of just what it is the
program is supposed to do
Steps in a Programming Project
• 2. Once you have a clear picture in your mind of the problem, you should
write out the specifications that the program is to satisfy.
• As a simple example, suppose you wish to write a program that sorts a list
of numbers into ascending order. Even for such a simple program, you
need to consider the specifications before you put finger to keyboard.
• For example, how are the numbers to be input into the program?
• Will they be typed in from the keyboard or read from a file?
• Will the quantity of numbers be known in advance, or should this quantity be
requested from the user before the numbers are read, or should the program
count the numbers as they are read in?
• Where is the sorted list to be output (on screen or in a file)?
• If files are used for input and/or output, are the filenames to be constant,
or should the program request the filenames from the user?
• Should the program be able to sort integers or real numbers as well?
Steps in a Programming Project
• You should have made up your mind on all these points before you
even sit down in front of the computer.
• Failing to think things through at this stage can mean a lot of
chopping and changing in the program later, which leads to jumbled
code that is full of errors, and difficult to debug, as well as a lot of
wasted time.

3. Having decided exactly what the specifications of the program are,

you must now consider the coding of it. There are two aspects to be
solved here. First, you must decide what data structures are to be used
to represent the entities in the program. Second, you must decide what
algorithm you are going to use to do the calculations.
Steps in a Programming Project
• Example: In coding a sorting program, for example, you must decide how
you are going to store the numbers to be sorted.
• If the maximum quantity of numbers is known in advance, an array may be the best
way.
• If the quantity varies a lot from one run to the next, a linked list (a data structure in
which space is allocated for data as it is needed, not reserved in advance as in an
array) may be more appropriate.
• If the numbers are associated with other data, it might be better to use an array or
linked list of records, in which one field represents the number which is used as the
sorting key.
• If you have considered the specifications properly, the choice of data
structure is usually a lot easier.
• The choice of which algorithm to use is often closely linked with the
specifications and the choice of data structures. There are a great many
sorting algorithms around (insertion sort, bubble sort, quicksort, mergesort,
etc.).
Steps in a Programming Project
• Different algorithms work best in different situations-some sorting
algorithms are more efficient when the list to sort is short, others are
better when the list is long.
• Some algorithms move the data around less than others, so if each
chunk of data is fairly large, meaning that moving it is expensive in
computer time, it would be better to use one of the former
algorithms.
• If each datum is only a single integer, so that moving it is fairly cheap,
one of the other algorithms may be better. If the program will be
handling lists of different sizes, it may even be worthwhile to include
more than one sorting algorithm, and choose the right one for the
length of list currently being sorted.
Steps in a Programming Project
• The steps up to now could all be done away from the computer, but
you must now write the actual code. There are many guidelines which
are appropriate here, but we will consider these in a moment. Overall,
the goal is to write clear, well documented, easy to read code that will
be easy for both you and someone else to understand and update at
some time in the future.
• Once the program is written, it must be tested against its
specifications. Actually, it is a good idea to make testing an integral
part of the code writing process. Since properly written code uses the
top-down (stepwise refinement) process, you will be writing
individual functions and procedures to do separate tasks. You should
test each of these modules as you write it
Steps in a Programming Project
• If a module calls other modules which you haven't written yet, create a dummy or stub
module with a simple writeln statement in it so that your module has something to
call. If you make sure that each module works as you write it, you ease the task of
debugging things later on.
• Once the entire program is complete, though, you must perform a set of
comprehensive tests on it to make sure it lives up to its specifications.
• Try it first with all forms of acceptable input for which it was designed and make sure
it behaves correctly.
• However, one aspect (the most difficult one) of testing is to try to anticipate all the
forms of incorrect input that users will feed your program. For example, suppose your
array sorting program is only designed to handle lists of up to 100 numbers.
• What will it do if someone feeds in 200? Or, if the program is designed to read a fixed
quantity of numbers from a file with a fixed name, what will the program do if the file
contains too few numbers, or if the file doesn't exist at all?
• In most cases like this, the program will just crash with an obscure error message, like
'Segmentation fault' or 'Trace-trap error', which will mean nothing to a naive user.
Steps in a Programming Project
• You should try to anticipate as many of these problems as you can, and write
your program to catch these errors and print out friendly error messages that let
the user know exactly what is wrong.
• One of the best ways of doing this is have a friend (preferably a sadistic one)
consciously try to break your program by feeding it all sorts of garbage input.
• You will find that there are quite a few input errors that you haven't thought of.
• Although this sort of testing is very important when you write programs in a
commercial or industrial environment, you won't have enough expertise at
present to be able to correct all the possible incorrect input situations.
• For example, how do you guard against someone entering text characters when
your program expects numbers?
• To trap all these cases requires some fairly sophisticated techniques which you aren't
expected to know at this stage.
• However, you should be thinking about making your program as user-friendly as
possible by allowing for simple errors that you do know how to fix.
Steps in a Programming Project
• Test the program with values that produce calculations that are
simple enough to check by hand.
• Test the program with realistic values (ones that the program would
expect to use in practice).
• Test the extreme cases (when you use all the space allocated in an
array, the highest or lowest acceptable number, etc.).
• Test what happens when inadequate or no input is present, especially
from a file.
• Test what the program does for `garbage input'. Try to produce
sensible error messages and thus avoid the GIGO (garbage in, garbage
out) syndrome.
• Make sure that every module in your program is actually used in one
of the test situations.