Coding and Testing

1
 Introduction
 Design Phase(Design Document) Coding
 Each module: Coded and Unit tested(in isolation)

 Coding  Integration and System Testing

 Partially integrated System + add additional modules
repeat
 Integration Testing

 As per integration plan

 Full product : System Testing --- Tested against SRS

 Testing: Largest Manpower / In parallel 2

 Coding
 Design:
 High Level Design
 Modular Structure

 Detailed Design
 Algorithm and Data Structure

 Modules are coded

 according to respective module specifications

3
 Coding..
 Objective:
 transform the design of a system into code in a high-
level language, and

 then to unit test this code.

 Should adhere to coding standard

 Well defined and standard coding style

 Organisation dependent

4
 Coding..
 Coding Standard Advantages:

 A coding standard gives

 a uniform appearance to the codes

 written by different engineers.

 It facilitates
 code understanding and code reuse.

 It promotes
 good programming practices. 5
 Coding..
 Coding Standards(Mandatory)
 Naming variables

 The way code is to be laid out

 The error return conventions …….

 Verified during code inspection

 Coding Guidelines(Optional)
 General suggestions regarding the coding style
 Actual implementation left to the developer
6
 Coding..

 Code Review
 Coding standard are followed or not?

 Detect as many errors as possible

 Efficient way of removing errors

7
Coding Standards and
Guidelines

8
Representative Coding
Standards

9
 Coding Standards and
Guidelines
Representative coding standards:
 Rules for limiting the use of globals:
 It list

 what types of data can be declared global

 and what cannot

10
 Coding Standards and
Guidelines
 Standard headers for different
modules:

 The header of different modules should

have standard format and information for

 ease of understanding and maintenance.

11
 Coding Standards and
Guidelines
 Standard headers for different
modules:
 Example Header Format:
 Name of the module.
 Date on which the module was created.
 Author’s name.
 Modification history.

12
 Coding Standards and
Guidelines
 Standard headers for different
modules:


 Synopsis of the module.

 Different functions supported in module
 Global variables accessed/modified by the
module. 13
 Coding Standards and
Guidelines
 Naming conventions for global variables,
local variables, and constant identifiers:

 A popular naming convention is that

variables are named using mixed case
lettering.

14
 Coding Standards and
Guidelines
 Naming conventions for global variables,
local variables, and constant identifiers:


 Global variable names would always start

with a capital letter (e.g., GlobalData) and
 local variable names start with small letters
(e.g., localData).
 Constant names should be formed using
capital letters only (e.g., CONSTDATA). 15
 Coding Standards and
Guidelines
 Conventions regarding error return values
and exception handling mechanisms:
 The way error conditions are reported by
different functions in a program
 should be standard within an organisation.


16
 Coding Standards and
Guidelines
 Conventions regarding error return values
and exception handling mechanisms:


 For example, all functions while

encountering an error condition should
either return a 0 or 1 consistently.
 This facilitates reuse and debugging.

17
Representative Coding
Guidelines

18
 Coding Standards and
Guidelines
Representative coding guidelines:
 Do not use a coding style that is
too clever or too difficult to understand:

 writing cryptic and incomprehensible code.

 Clever coding can obscure meaning of the code

and reduce code understandability

 thereby making maintenance and debugging

difficult and expensive. 19
 Coding Standards and
Guidelines
Representative coding guidelines:
 Avoid obscure side effects:
 The side effects of a function call include
 modifications to the parameters passed by
reference,
 modification of global variables, and I/O
operations.

20
 Coding Standards and
Guidelines
Representative coding guidelines:
 Avoid obscure side effects:
 The side effects of a function call include
 modifications to the parameters passed by reference,
 modification of global variables, and I/O operations.
 An obscure side effect is one that is not
obvious from a casual examination of the
code.
 Obscure side effects make it difficult to
understand a piece of code.

21
 Coding Standards and
Guidelines
Representative coding guidelines:
 Avoid obscure side effects:
 The side effects of a function call include

 For example, suppose the value of a global

variable is changed or some file I/O is
performed obscurely in a called module.
 That is, this is difficult to infer from the
function’s name and header information.
 Then, it would be really hard to understand
the code. 22
 Coding Standards and
Guidelines
Representative coding guidelines:
 Do not use an identifier for multiple

purposes:
 Programmers often use the same identifier to
denote several temporary entities.

 For example, some programmers make use of

a temporary loop variable for
 computing and storing the final result.

23
 Coding Standards and
Guidelines
Representative coding guidelines:
 Do not use an identifier for multiple

purposes:
 The rationale that they give for such multiple
use of variables is memory efficiency,
 e.g., three variables use up three memory
locations,
 whereas when the same variable is used for three
different purposes, only one memory location is used.
 However , there are several things wrong with
this approach and hence should be avoided.
24
 Coding Standards and
Guidelines
Representative coding guidelines:
 Do not use an identifier for multiple
purposes: Some of the Problems

 Each variable should be given a descriptive name

indicating its purpose.
 This is not possible if an identifier is used for

multiple purposes.
 Use of a variable for multiple purposes can

lead to confusion and make it difficult for

somebody trying to read and 25
 Coding Standards and
Guidelines
Representative coding guidelines:
 Do not use an identifier for multiple
purposes: Some of the Problems

 Use of variables for multiple purposes usually

makes future enhancements more difficult.
 For example, while changing the final

computed result from integer to float type,

 the programmer might subsequently notice

that it has also been used as a temporary loop

variable that cannot be a float type. 26
 Coding Standards and
Guidelines
Representative coding guidelines:

 Code should be well-documented:

 As a rule of thumb, there should be at least one

comment line on the average

 for every three source lines of code.

27
 Coding Standards and
Guidelines
Representative coding guidelines:
 Length of any function should not
exceed 10 source lines:
 A lengthy function is usually very difficult to
understand as it probably has
 a large number of variables and

 carries out many different types of

computations.

 For the same reason, lengthy functions are likely

to have disproportionately larger number of 28
 Coding Standards and
Guidelines
Representative coding guidelines:

 Do not use GO TO statements:

 Use of GO TO statements makes a program

unstructured.

 This makes the program very difficult to understand,

debug, and maintain.

29
Code Review

30
 Code Review
Review is a very effective technique to remove
defects from source code.

In fact, review has been acknowledged

 to be more cost-effective in removing
defects as compared to testing.

31
 Code Review
 Code review for a module is undertaken
 after the module successfully compiles.

 Obviously, code review does not target to

design syntax errors in a program,

 but is designed to detect

 logical, algorithmic, and programming errors.

32
 Code Review
 The reason behind why code review is a much
more cost-effective strategy to eliminate errors
from code compared to testing is that
 reviews directly detect errors.

 On the other hand, testing only helps detect

failures and
 significant effort is needed to locate the
error during debugging.

 What is the rationale behind the above

statement ? 33
 Code Review
 The rationale behind the above statement is
explained as follows.

 Eliminating an error from code involves three main

activities—
 testing, debugging, and then correcting the
errors.

 Testing is carried out to detect if the system fails to

work satisfactorily
 for certain types of inputs and
 under certain circumstances. 34

 Code Review
 The rationale behind the above statement is
explained as follows….

 Once a failure is detected, debugging is carried out to

locate the error
 that is causing the failure and to remove it.

 Of the three testing activities,

 debugging is possibly the most laborious and time
consuming activity.

 In code inspection, errors are directly detected,

thereby saving the significant effort that would have
35

been required to locate the error

 Code Review
 Normally, the following two types of
reviews are carried out on the code of
a module:

 Code walkthrough.

 Code inspection.

36
 Code Review

Code walkthrough.

37
 Code Review
 Code walkthrough.
 Code walkthrough is an informal code analysis
technique

 In this technique, a module is taken up for

review after the module has been

 coded, successfully compiled, and all syntax

errors have been eliminated.
38


 Code Review
 Code walkthrough.
 Code walkthrough is an informal code analysis
technique.


 A few members of the development team are

given the code a couple of days before the
walkthrough meeting.
39
 Code Review
 Code walkthrough
 Each member selects some test cases and
simulates execution of the code by hand (i.e.,
traces the execution through different
statements and functions of the code).

 The members note down their findings of their

walkthrough and discuss those in a walkthrough
meeting where the coder of the module is
present. 40
 Code Review
 Code walkthrough.
 Even though code walkthrough is an informal
analysis technique,
 several guidelines have evolved over the
years for making this naive but useful
analysis technique more effective.


41
 Code Review
 Code walkthrough.


 These guidelines are based on personal

experience, common sense, several other
subjective factors.
 Therefore, these guidelines should be
considered as examples rather than as
accepted rules to be applied dogmatically. 42
 Code Review
 Code walkthrough
 Some of these guidelines are following:
 The team performing code walkthrough
should not be either too big or too small.

 Ideally, it should consist of between three

to seven members.

 Discussions should focus on discovery of

errors and avoid deliberations on how to
fix the discovered errors. 43
 Code Review
 Code walkthrough.
 Some of these guidelines are following:

 In order to foster co-operation and to avoid

the feeling among the engineers that they
are being watched and evaluated in the code
walkthrough meetings,

 managers should not attend the

walkthrough meetings.
44
 Code Review

Code inspection.

45
 Code Review
 Code Inspection
 During code inspection, the code is
examined for the presence of
 some common programming errors.

 This is in contrast to the hand simulation

of code execution carried out
 during code walkthroughs.


46
 Code Review
 Code Inspection
 principal aim of the code inspection:
 is to check for the presence of some
common types of errors that usually
creep into code due to
 programmer mistakes and oversights
and
 to check whether coding standards have
been adhered to.
47
 Code Review
 Code Inspection
 The inspection process has several
beneficial side effects, other than
finding errors.

 The programmer usually receives

feedback on
 programming style,
 choice of algorithm, and
 programming techniques.
48
 Code Review
 Code Inspection
 The inspection process has several
beneficial side effects, other than
finding errors.

 The other participants gain by being

exposed to another programmer’s
errors. 49
 Code Review
 Code Inspection
 In addition to the commonly made
errors, adherence to coding standards
is also checked during code inspection.

52
 Code Review
 Code Inspection

 Good software development companies

collect statistics regarding different
types of errors
 that are commonly committed by their
engineers and identify the types of
errors most frequently committed. 53
 Code Review
 Code Inspection
 Such a list of commonly committed
errors can be used as a
 checklist during code inspection to look
out for possible errors.

54
 Code Review
 Code Inspection
Following is a list of some classical
programming errors which can be checked
during code inspection:
 Use of uninitialised variables.
 Jumps into loops.
 Non-terminating loops.
 Incompatible assignments.
 Array indices out of bounds.
 Improper storage allocation and 55
 Code Review
 Code Inspection
 Mismatch between actual and formal
parameter in procedure calls.
 Use of incorrect logical operators or
incorrect precedence among operators.
 Improper modification of loop variables.
 Dangling reference caused when the
referenced memory has not been allocated.

56
 Code Review

Clean Room Testing

57
 Code Review
 Clean Room Testing
 Clean room testing was pioneered at IBM.
This type of testing relies heavily on
 walkthroughs,
 inspection, and
 formal verification.

 not allowed to test any of their code by

executing the code other than doing
some syntax testing using a compiler .
58
 Code Review
 Clean Room Testing
 It is interesting to note that the
term cleanroom was first coined at
IBM by drawing analogy to

 the semiconductor fabrication

units where defects are avoided
by manufacturing in an ultra-clean
atmosphere. 59
 Code Review
 Clean Room Testing

 This technique reportedly produces

a code that is more reliable and
maintainable

 than other development methods

relying heavily on code execution-
based testing. 60
 Code Review
 Clean Room Testing
 The main problem with this approach is that
testing effort is increased
 as walkthroughs, inspection, and
verification are time consuming for
detecting all simple errors.
 Also testing- based error detection is
efficient for
 detecting certain errors that escape
manual inspection 61
Software Documentation

62
 Software Documentation
 When a software is developed, in
addition to the executable files and
the source code,
 several kinds of documents such as
 users’ manual,
 software requirements specification
(SRS) document,
 design document,
 test document, etc., are developed
63
 Software Documentation
 Good documents are helpful in the
following ways:
 Good documents help
 enhance understandability of code.
 the users to understand and effectively
use the system.
 effectively tackle the manpower
turnover problem.
 the manager to effectively track the
progress of the project. 64
 Software Documentation
 Types of software documents:
 Internal documentation: These are
provided in the source code itself.

 External documentation: These are

the supporting documents such as
SRS document, installation document,
user manual, design document, and
test document. 65
 Internal Documentation
 Internal documentation is the code
comprehension features provided in
the source code itself.
 Types of internal documentation:
 Comments embedded in the source
code.
 Use of meaningful variable names.
 Module and function headers.
66
 Internal Documentation
Types of internal documentation:
 Code indentation.
 Code structuring (i.e., code
decomposed into modules and
functions).
 Use of enumerated types.
 Use of constant identifiers.
 Use of user-defined data types.
67
 Internal Documentation
 Most valuable for understanding a
piece of code?
 Careful experiments suggest that out
of all types of internal documentation,
meaningful variable names is most
useful while trying to understand a
piece of code.

68
 External Documentation
 A systematic software development
style ensures that all these(SRS….)
documents
 are of good quality and
 are produced in an orderly fashion.

69
 External Documentation
 An important feature that is
required of any good external
documentation is
 consistency with the code.
 all the documents developed for a
product should be up-to-date
 proper understandability by the
category of users for whom the
document is designed.
 Gunning’s fog index 70
 External Documentation
 Gunning’s fog index (developed by Robert
Gunning in 1952) is a metric that has been
designed to measure the readability of a
document.
 number of years of formal education that a
person should have, in order to be able to
comfortably understand that document.
 a fog index of 12, any one who has completed
his 12th class would not have much difficulty
in understanding that document.
71
 External Documentation
 The Gunning’s fog index of a document D
can be computed as follows:

 the average number of words per sentence (total

number of words in the document divided by the total
number of sentences).

 the percentage of complex words in the document.

72
 External Documentation
Example:
Calculate its Fog index for the sentence:

“The Gunning’s fog index is based on the

premise that use of short sentences
and simple words makes a document easy
to understand.”

73
 External Documentation
Example: Calculate its Fog index for the
sentence: “The Gunning’s fog index is based on
the premise that use of short sentences and
simple words makes a document easy to
understand.”
 The fog index of the above example
sentence is:

0.4(23/1) + (4/23)100 = 26
74