Coding

The goal of coding is to translate the design of the system (produced during the design phase) into code in a specific language. The input to the coding phase is design document. The coding phase affects both testing phase and maintenance phase greatly. Time spent in coding is small as compared to other phases. But coding has a great impact on testing and maintenance. A well written code can make testing and maintenance easy. The goal in coding should not be to reduce implementation cost but to reduce the cost of later phases. The goal is not to simplify the job of programmer but to simply the job of tester and maintainer.

Normally, good software development organizations adhere to some well-defined and standard style of coding. These are called coding standards.

Main reasons to follow a standard coding style is:

• All the modules are written in a uniform style.
• It encourages good programming practices among programmers.
• It improves code understanding.
• The well written code is easy to test and maintain.

Programming Practices

Some of the often used programming practices are:

• Top down and Bottom up
• Structured programming
• Information Hiding

Top down and Bottom up

In top down implementation, the implementation starts from top level and proceeds to lower levels. In this, first the main module is coded then its subordinate modules are implemented. This process is repeated until all the modules and their subordinates are implemented.

In bottom up implementation the development starts from the bottom of hierarchy and proceeds to the higher levels. Top down and bottom up approaches are reverse of each other.

Although design may be top down or bottom up. But a top down design can be implemented in bottom up style or bottom up design can be implemented in top down style.

In a large system combination of two approaches is used during coding. Although the modules can be coded in random way. But if we follow top down or bottom up approach the testing of modules will be easy. In top down approach we construct a stub for lower level modules. A higher level module call its stub to check its functioning. In bottom up approach all the modules in lower levels are constructed and driver modules are needed to invoke these modules.

Structured Programming

A program is called structured if it uses sequences selection and iteration type of constructs. Use of goto is avoided. In other words it avoids unstructured control flow.

The property of structured programming is that it has a single entry and single exit. At the time of execution structured statements starts from one point and terminate at defined point. The most commonly used single entry and single exit statements are

• Selection (if-else)
• Iteration (loops like while, repeat until etc.)

The basic objective of structured programming to make the flow of program linear. For the same reason use of goto is avoided. If the flow of the program is linear that will be very easy to understand.

The basic objective of software engineering is that overall cost of software should be reduced. Structured programming is a good approach to achieve this goal. But in actual practice there may not be any program which is not using unstructured constructs like goto, continue or break statements. But these constructs should be used rarely and when the structured substitute is not possible.

Information Hiding

In this kind of programming the information is represented as data structures. Some defined operations are allowed on these data structures. All other operations which are not defined are not performed. This is called principle of information hiding. The information stored in a data structure is hidden from the rest of the system. Only access functions of data structures are visible. The information in those data structures is changed through these functions. Access rights may also be given to those functions. So the data structures are not used by other modules directly. This approach is used in object oriented programming.

A module can see only those data items (data structure) those are needed by it, or we can say that information is hidden. Information hiding can reduce the coupling between two modules and make the system more maintainable.

Programming Style

Following are some general rules that usually apply for good programming practice.

1. Name of variable and modules: The variable name and module name should be closely related to their work. Name should reflect their entity or activity. We should not use cryptic names to avoid typing. Same name should not be used for multiple purposes.

2. Use of Goto should be avoided: The gotos should be used rarely and with case. Although the use of goto should be avoided but in case it is necessary to use goto then it should be used for forward jump than backward jump. If the goto is used to invoke an error handler then if the language provides separate constructs for that, like java, that should be used.

3. Control Constructs: Single entry single exit constructs should be used as much as possible.

4. User defined type: Modern languages allows users to define data types like enumerated type. These facilities should be used as much ass possible. Using such types makes program more clearer.

5. Nesting: Deep nesting of if-else constructs should be avoided. If nesting becomes too deep it is difficult to understand.

6. Size of module: Any module of less than five statements and more than twenty-five statements should be avoided.

7. Program layout: Comments should be used in program, proper indentation of program should be done. Use of blank spaces and parenthesis should be used to improve readability.

8. Side effects: If a module is changing variables those are not listed in module definitions, that should be properly documented. Ex: If a module is modifying a global variable that should be documented. Such side effects should be avoided.

9. Module interface: A module with to much parameters should be examined very carefully. This should be broken if possible. A module with more than five parameters should be broken if possible.

Documentation: This is of two types:

1. Internal documentation

2. External documentation

Various kinds of documents are prepared in the life cycle of a project like SRS, design documents, user manuals, test documents, installation documents. These documents make a software easy to understand and maintain.

Internal documentation is a part of the program. In this name of the author, copyright information, date of creation, version, etc are mentioned. This is also provided through the use of meaningful variable names, indentation of code, using enumeration data types, etc. The comments also play a vital role in internal documentation.

External documentation are provided in the form of SRS, design documents, test documents, user manuals, etc. Each phase in software development generate documents.

Verification

Verification of code is done for detecting errors introduced in coding phase. The goal of verification is to show that produced code is consistent with design document.

Program verification can be done by two ways

• Dynamic methods
• Static methods

In dynamic verification method the program is executed on some test data, the outputs of program are examined to detect any error.

Static Verification Methods: In these techniques the program is not executed, but verification of code is done by code reading, code reviews and walkthroughs. In this technique, the presence of error is detected not the source of the error.

Code Reading: In this method careful reading of code is done to find discripencies between design and the code. In design we start from an abstraction and move toward more details. In code reading we start from the details and move toward abstraction.

Code reading can detect errors often not detected by testing. Code reading also focus the programmer to code in a manner conducive to the process. This leads to well structured program.

Code Walkthroughs: This is an informal technique for the analysis of code. When the coding of a module is complete, then code walkthrough is done. In this members of project team develop some test cases and simulate the execution of code by hand. There are some guidelines for code walkthrough

l The number of members doing code walkthrough should not be either too large or too small. Ideal team size is between three to seven.

l Purpose of code walkthrough should be to find errors not how to fix errors.

Code Inspection (Code reviews): The code inspection is done to find commonly made errors. In code walkthrough, code is simulated by hand, but in this the code is checked for certain kinds of errors. The following are the commonly made mistakes in coding:

• Non terminating loops
• Array indices out of bound
• Jump into loops
• Use of uninitialized variables
• Mismatch in function definition and function call
• Equality of floating points