Approaching Coding of Modularized Programs

The approach that some follow when programming is to write all of the code into the compiler before compiling the program for the first time. They do this by taking the structure chart and the pseudo code and then convert these documents into the language chosen for the program. After each of these has been translated into the language, they compile it for the first time. Many times this approach fails. After compiling, they find many syntax and warning errors. Sometimes the number of errors may be in the hundreds in a large program. Trying to remove these errors may take hours especially in large programs. It may in some cases require a complete rewriting of the program.

There are many reasons for the failure of this approach. First the structure chart and the pseudo code are not written in specific programming language syntax. Therefore there may be errors in the translation from the structure chart or the pseudo code into the programming language.

In addition, neither the structure chart nor the pseudo code requires definitions of the data variables. Sometimes if the code does define all of the variables, some of the variables may have been defined with the wrong data attributes.

Another error may be that the variable is not initialized or not initialized correctly.

Each of these types of errors may cause syntax errors, warning errors, run time errors or even logical errors.

Another type of error can be forgetting that a statement in C++ must end in a semicolon and the semicolon is left off thereby causing a syntax error.

Some errors in modularization can be that a function was not declared, defined or even called correctly. If the declaration of the function is the prototype, the semicolon at the end may be left off. Some times in error a semicolon is placed at the end of the function definition's header. It could also happen that the signatures of the declaration, the definition and the calls do not agree. Another error in modularization may be caused by using different variable names or data types in the signature from those in the body of the function definition or the call. If a module uses passing by pointer or passing by reference, then the body of the module may not take this into consideration.

The approach to debugging syntax and warning errors is frequently starting at the first compiler error message listed. If you double click on the error message in Visual Studio .NET, the compiler will move the cursor to a statement in the code. However the error may not be at that point. The error may be somewhere above that point. What the programmer needs to do is to use the error message and then look at that line and as well as those lines above to determine why that error occurred. Many times the error is not the line where the compiler moved the cursor but above it.

Once you have removed an error, you have one of two choices: 1) check the next error message listed and try to remove it or 2) recompile the program to see what errors are listed now. Either of these approaches may be used. However as the number of modifications made to the program increases, the choice should be to recompile. What may happen is that the correction of one error may correct one or more additional errors. Therefore you may waste your time trying to remove listed errors that no longer exist.

Examples for debugging (for each of the following programs compile it and then remove the syntax and warning errors):

• payables.cpp

• gender.cpp

Another approach to coding especially for larger programs is not to wait until the program has been completely written before you compile but to compile the program as you proceed with the writing. To compile a program takes relatively little time especially when compared to the time needed to visually find the errors.

For example, you should first place any headers needed into the program, define any global variables and write main() in the proper format. This should be followed by writing the declarations and definitions of the modules using the pseudo code and the structure chart to determine what modules need to be defined. In this first step, it is recommended that the body of the definition should be empty except for the definitions and initialization of any variables that are to be returned. In main() write the definitions and initialization of any local variables needed in the module calls both as arguments and as variables to receive the output of modules. After all of these steps have been followed, the program should be compiled for the first time. Since there are far fewer lines in the code at this point, it will be much easier to find any syntax and warning errors.

Next take the pseudo code for body of main() and write the code for it. After all of the code in main() has been written, recompile the program and remove any errors.

As the next step, write each module's complete definition one at a time. After each of these definitions has been completed, compile the program once again until all of the modules have been completely defined and all of the syntax errors have been removed.

At this point all of the syntax and warning errors should have been removed and it is time to check for logical errors. Using the sample data of the specification phase, the program should be run on the sample data.

For large programs, this second approach to writing and compiling listed above should be far more efficient than the first method. It takes far less time to remove a syntax or warning error from a partially completed program than from a fully completed program.