Unit-4

Coding
P.Sindhu
Asst.Professor©
CSE Dept
 Contents
• Implementation
• Coding Standard and Guidelines
• Review
• Unit Testing
• Verification and Validation
 Introduction
• The objective of the coding phase is to transform the design
of a system into code in a high level language and then to
unit test this code.
• The programmers adhere to standard and well defined style
of coding which they call their coding standard.
• The main advantages of adhering to a standard style of
coding are as follows:
– A coding standard gives uniform appearances to the code
written by different engineers
– It facilitates code of understanding.
– Promotes good programming practices. For implementing our
design into a code, we require a good high level language.
 Contd…
Characteristics of a Programming Language
• Readability:
– A good high-level language will allow programs to be written in some
ways that resemble a quite-English description of the underlying
algorithms. If care is taken, the coding may be done in a way that is
essentially self-documenting.
• Portability:
– High-level languages, being essentially machine independent, should
be able to develop portable software.
• Generality:
– Most high-level languages allow the writing of a wide variety of
programs, thus relieving the programmer of the need to become
expert in many diverse languages
• Brevity:
– Language should have the ability to implement the algorithm with
less amount of code. Programs expressed in high-level languages
are often considerably shorter than their low-level equivalents.
• Error checking:
– Being human, a programmer is likely to make many mistakes in
the development of a computer program. Many high-level
languages enforce a great deal of error checking both at compile-
time and at run-time.
• Cost:
– The ultimate cost of a programming language is a function of
many of its characteristics.
• Familiar notation:
– A language should have familiar notation, so it can be understood by most of
the programmers.
• Quick translation:
– It should admit quick translation.
• Efficiency:
– It should permit the generation of efficient object code.
• Modularity:
– It is desirable that programs can be developed in the language as a collection
of separately compiled modules, with appropriate mechanisms for ensuring
self-consistency between these modules.
• Widely available:
– Language should be widely available and it should be possible to provide
translators for all the major machines and for all the major operating systems.
 Coding Standards and Guidelines
• Good software development organizations usually
develop their own coding standards and guidelines
depending on what best suits their organization
and the type of products they develop.
• The following are some representative coding
standards.
1. Rules for limiting the use of global:
• These rules list what types of data can be declared
global and what cannot.
 2. Contents of the headers preceding codes for different modules:
The information contained in the headers of different modules
should be standard for an organization. The exact format in which the
header information is organized in the header can also be specified.
The following are some standard header data:
– Name of the module.
– Date on which the module was created.
– Author’s name.
– Modification history.
– Synopsis of the module.
– Different functions supported, along with their input/output
parameters.
– Global variables accessed/modified by the module.
3.Naming conventions for global variables, local variables,
and constant identifiers:
– A possible naming convention can be that global variable names
always start with a capital letter, local variable names are made
of small letters, and constant names are always capital letters.
4. Error return conventions and exception handling
mechanisms:
– The way error conditions are reported by different functions in a
program are handled should be standard within an organization.
For example, different functions while encountering an error
condition should either return a 0 or 1 consistently.
5.Do not use a coding style that is too clever or
too difficult to understand
6.Avoid obscure side effects
7.Do not use an identifier for multiple purposes
8.The code should be well-documented:
– As a rule of thumb, there must be at least one comment line on
the average for every three-source line.
9. The length of any function should not exceed 10 source
lines:
– A function that is very lengthy is usually very difficult to
understand as it probably carries out many different functions.
For the same reason, lengthy functions are likely to have
disproportionately larger number of bugs.
10. Do not use goto statements:
– Use of goto statements makes a program unstructured and
very difficult to understand.
 Code Review
• Code review for a model is carried out after the module is
successfully compiled and the all the syntax errors have
been eliminated.
• Code reviews are extremely cost-effective strategies for
reduction in coding errors and to produce high quality
code.
• Normally, two types of reviews are carried out on the
code of a module.
• These two types code review techniques are
– code inspection
– code walk through.
 Code Walk Throughs
• Code walk through is an informal code analysis technique. In
this technique, after a module has been coded, successfully
compiled and all syntax errors eliminated. A few members of
the development team are given the code few days before
the walk through meeting to read and understand code. Each
member selects some test cases and simulates execution of
the code by hand (i.e. trace execution through each
statement and function execution). The main objectives of
the walk through are to discover the algorithmic and logical
errors in the code. The members note down their findings to
discuss these in a walk through meeting where the coder of
the module is present.
• Even though a code walk through is an informal analysis
technique, several guidelines have evolved over the years for
making this naïve but useful analysis technique more effective.
Of course, these guidelines are based on personal experience,
common sense, and several subjective factors. Therefore,
these guidelines should be considered as examples rather than
accepted as rules to be applied dogmatically.
• Some of these guidelines are the following:
– The team performing code walk through should not be either too big
or too small. Ideally, it should consist of between three to seven
members.
– Discussion should focus on discovery of errors and not on how to fix
the discovered errors.
– In order to foster cooperation and to avoid the
feeling among engineers that they are being
evaluated in the code walk through meeting,
managers should not attend the walk through
meetings.
 Code Inspection
• In contrast to code walk through, the aim of code inspection is
to discover some common types of errors caused due to
oversight and improper programming. In other words, during
code inspection the code is examined for the presence of
certain kinds of errors, in contrast to the hand simulation of
code execution done in code walk throughs.
• For instance, consider the classical error of writing a
procedure that modifies a formal parameter while the calling
routine calls that procedure with a constant actual parameter.
It is more likely that such an error will be discovered by
looking for these kinds of mistakes in the code, rather than by
simply hand simulating execution of the procedure.
• In addition to the commonly made errors,
adherence to coding standards is also checked
during code inspection. Good software
development companies collect statistics
regarding different types of errors commonly
committed by their engineers and identify the
type of errors most frequently committed.
• Such a list of commonly committed errors can be
used during code inspection to look out for
possible errors.
• Following is a list of some classical programming errors which can
be checked during code inspection:
– Use of uninitialized variables.
– Jumps into loops.
– Nonterminating loops.
– Incompatible assignments.
– Array indices out of bounds.
– Improper storage allocation and deallocation.
– Mismatches between actual and formal parameter in procedure calls.
– Use of incorrect logical operators or incorrect precedence among
operators.
– Improper modification of loop variables.
– Comparison of equally of floating point variables, etc.
 Verification Vs Validation
• Verification is the process of determining whether
the output of one phase of software development
conforms to that of its previous phase,
• whereas validation is the process of determining
whether a fully developed system conforms to its
requirements specification.
• Thus while verification is concerned with phase
containment of errors, the aim of validation is
that the final product be error free.
Testing in the large vs. testing in the small

• Software products are normally tested first at

the individual component (or unit) level. This is
referred to as testing in the small.
• After testing all the components individually, the
components are slowly integrated and tested at
each level of integration (integration testing).
• Finally, the fully integrated system is tested
(called system testing). Integration and system
testing are known as testing in the large.
 Unit Testing
• Unit testing is undertaken after a module has been coded and
successfully reviewed.
• Unit testing (or module testing) is the testing of different units (or
modules) of a system in isolation.
• In order to test a single module, a complete environment is needed to
provide all that is necessary for execution of the module. That is,
besides the module under test itself,
• the following steps are needed in order to be able to test the module:
– The procedures belonging to other modules that the module under test
calls.
– Nonlocal data structures that the module accesses.
– A procedure to call the functions of the module under test with appropriate
parameters.
• Modules are required to provide the necessary
environment (which either call or are called by the
module under test) is usually not available until they
too have been unit tested
• stubs and drivers are designed to provide the
complete environment for a module.
• The role of stub and driver modules is pictorially
shown in fig. .
Unit testing with the help of driver and stub
modules
• A stub procedure is a dummy procedure that has the
same I/O parameters as the given procedure but has
a highly simplified behavior.
• For example, a stub procedure may produce the
expected behavior using a simple table lookup
mechanism.
• A driver module contain the nonlocal data structures
accessed by the module under test, and would also
have the code to call the different functions of the
module with appropriate parameter values
Thank You….