The Programming Style

In earlier section we saw that how a flowchart is evolved to solve a problem. The flowchart is just an aid to the programmer to plan his strategy to solve a problem A computer can not directly interpret it. A computer can interpret it only if it is coded into low-level language (machine or assembly) or high-level language. Unfortunately it is not always possible to write complex programs in low-level language. Therefore computer programs may be written in a into high-level language. The concept of programming involves more than simply writing a program. In addition, using meaningful names to variables and functions, documentation and maintenance of programs are important parts of programming.

Documentation

Documentation is just a written text and comments that make a program easier for others to understand, use and modify. Documentation should be kept up to date. Any change made in the program should be marked in all of the pertinent documentation. As far as small programs are concerned you indeed can keep all the details in your head, and so needs documentation only to explain the program to someone else. But as far as large and complex programs are concerned it becomes impossible to remember how every detail relates each other and therefore, it is essential that appropriate documentation be prepared along with each small part of the program. Thus the important point is that keep your documentation concise but descriptive.

Spaces, blank lines, and indentation in a program are an important form of documentation. These white space characters make the program easy to read, allow you to tell at a glance which parts of the program relate to each other, which statements are contained in which loop, and so on. In other words, you can say that using white space characters, it is easier to determine the structure of the program.

Once a program is fully debugged and in use, it is necessary to maintain it. Maintenance of programs is the modification of programs needed to meet new requests after they have been completed.

Naming Variables and Functions

While writing a program, one should give meaningful names to variables and functions so that their places in the program can be properly recognized and appreciated. Although finding good names is not an easy task, the careful choice of names go a long way in clarifying a program and in helping to avoid common errors. Let us see what should be kept in mind while selecting names.

1. Use the meaningful names for variables, constants and functions such that they should suggest clearly the purpose of variables and functions.
2. Use a single letter for the variable controlling a loop.
3. Use common prefixes or suffixes to associate names to variables and functions as:

ReadArray

DisplayArray

InsertElement

DeleteElement

1. Don’t use misspelling and meaningless suffices to the variables.
2. Don’t choose names that are close to the each other in spelling or otherwise be ready to confuse.

Debugging of Programs

The process of detecting and removing errors in a program is referred as program testing and debugging. No body is perfect, at least I am not. When we code the algorithm then it is not necessary that our program should be 100 percent error–free. It means that there may occur any type of errors in the program. And it is totally programmer’s duty to trace out such errors and correct them that are likely to be present in the program.

There are four basic types of errors:

1. Syntax errors
2. Run–time errors
3. Logical errors
4. Latent errors

Syntax Errors

Every programming language has its own set of rules and the errors, which violate such rules, are referred as syntax errors. Fortunately syntax errors are immediately detected and isolated by the compiler during compilation purpose. The compilation phase of the program would not be completed until any syntax error is present in the program.

Following are the example of some syntax errors:

1. int  area-square, radius-of-circle;                     /*  no hyphen */
2. float  10salary;                                                    /*  starts with a number sign  */
3. char @basic                                                     /*  starts with a @ sign  */

Normally the compiler specifies the line number where the error has occurred. But in some cases, the line number may not exactly indicate the place of error. So you have to find out that place.

Run–Time Errors

The errors, which occur during the runtime of a program, are referred as run–time errors or execution–time errors. Generally run–time errors come when there is any mismatch of basic data types or make an illegal reference and so on.

Logical Errors

The errors, which are directly related to the logic of the program, are referred as logical errors. Logical errors occurs due to wrong jumping, failure to satisfy a particular condition, and any incorrect order of evaluation of statements. Like run–time errors, the logical errors are not recognized by the compiler.

Following are the examples of some logical errors:

if (i=1)

{
stat1;
stat2;
}

Here instead of using logical equal to (==) operator we have used assignment operator (=). A test condition, like this, would always be result in true.

2. if (num==sum)

 
printf (“Both are equal”);

If ‘num’ and ‘sum’ are float types values, then it is not necessary to become equal due to truncation  error. Generally such type of errors occur due to incorrect coding of the algorithm.

Latent Errors

The errors that come in existence when we enter some special values during the execution of a program are called as latent errors. Consider the following statements:

1.  a = 1 / b;

In this statement an error occurs only when b is equal to 0.

2. x = 4 + c / (a-b);

Here an error occurs when ‘a’ and ‘b’ are equal.

Latent errors can be detected only by using all possible combination of test data.

Program Testing

Program testing is the process of running the program on sample data chosen to find errors, if they are present, before the program is used on actual data. Earlier we have discussed that the compiler can detect only the syntactic and semantics errors. All other errors can be traced out at run time only. Therefore it is necessary for the programmers to detect all such errors by taking some realistic data.

One of the most effective way to find errors is called a structured walkthrough. You can also call it as human testing. In this the programmer shows the complete source code to another programmer or a peer group. Structured walkthrough is carried out statement by statement by the programmer and is analyzed with respect to a checklist of common errors.

The testing should be done initially on function level and when all goes well then it should be made on the complete program level. When we talk about the program testing, it is also necessary to point out the quality of test data. The quality of test data should be selected in the following ways:

1. Easy values – The program is tested with data that are easy to check; otherwise the complicated data may embarrass the programmer.
2. Typical Realistic value – The testing data should be simple realistic so that the result can be checked by hand.
3. Extreme values – Testing should be done at the limits of his range of application.
4. Illegal values – The program should also be tested for some illegal values so that it becomes able to produce a sensible error message.

The ultimate conclusion is that program testing can be used to show the presence of errors but never their absence.