Coding

Prof. A. Acharya
Coding
⚫ Coding is undertaken once design phase is
complete.
⚫ During coding phase:
⚫ every module identified in the design
document is coded and unit tested.
⚫ Unit testing (aka module testing):
⚫ testing of different modules (aka units) of a
system in isolation.

2
Example Structured Design

root
rms
Valid-numbers
rms
Valid-numbers

Get-good-data Compute-solution Display-solution

Get-data Validate-data

3
Unit Testing

⚫ Many beginners ask:

⚫ Why test each module in isolation first?
⚫ then integrate the modules and again test the set
of modules?
⚫ why not just test the integrated set of modules
once thoroughly?

4
Unit Testing

■ It is a good idea to test modules in

isolation before they are integrated:
■ it makes debugging easier.

5
 Unit Testing
■ If an error is detected when several
modules are being tested together,
■ it would be difficult to determine which
module has the error.
■ Another reason:
■ the modules with which this module
needs to interface may not be ready.

6
 Integration Testing
⚫After all modules of a system have
been coded and unit tested:
⚫ integration of modules is done
according to an integration plan.

7
Integration Testing
⚫ The full product takes shape only after all the
modules have been integrated.

⚫ Modules are integrated together according to

an integration plan involves integration of the
modules through a number of steps.

8
Example: Integration from SD
root

Get-good-data Compute-solution Display-solution

Validate-data
Get-data

9
 Integration Testing
⚫ During each integration step, a number of
modules are added to the partially integrated
system and the system is tested.

⚫ Once all modules have been integrated and

tested, system testing can start.

10
 System Testing
⚫ During system testing:
the fully integrated system is tested
against the requirements recorded in the
SRS document.

11
Coding
⚫ The input to the coding phase is the design
document.
⚫ During coding phase:
⚫ modules identified in the design document
are coded according to the module
specifications.

12
Coding
⚫ At the end of the design phase we have:
⚫ module structure (e.g. structure chart) of the
system
⚫ module specifications:
⚫ data structures and algorithms for each module.

⚫ Objective of coding phase:

⚫ transform design into code
⚫ unit test the code.

13
Coding Standards
⚫ Good software development organizations
require their programmers to:
⚫ adhere to some standard style of coding
⚫ called coding standards.

14
Coding Standards
⚫ Many software development
organizations:
⚫ formulate their own coding standards
that suits them most,
⚫ require their engineers to follow
these standards rigorously.

15
Coding Standards, why?
⚫ Advantage of adhering to a standard style of
coding:
⚫ it gives a uniform appearance to the
codes written by different engineers,
⚫ it enhances code understanding,
⚫ encourages good programming practices.

16
Coding Standards
⚫ A coding standard sets out standard ways of
doing several things:
⚫ the way variables are named,
⚫ code is laid out,
⚫ maximum number of source lines
allowed per function, etc.

17
Coding guidelines
⚫ Provide general suggestions regarding
coding style to be followed:
⚫ leave actual implementation of the
guidelines to the discretion of the
individual engineers.

18
Code inspection and code walkthroughs

⚫ After a module has been coded,

⚫ code inspection and code walk through are
carried out
⚫ ensures that coding standards are followed
⚫ helps detect as many errors as possible
before testing.

19
Code inspection and code
walkthroughs
⚫ Detect as many errors as possible
during inspection and walkthrough:
⚫ detected errors require less effort for
correction
⚫ much higher effort needed if errors were
to be detected during integration or
system testing.

20
Coding Standards and
Guidelines
⚫ Good organizations usually develop
their own coding standards and
guidelines:
⚫ depending on what best suits their
organization.
⚫ We will discuss some representative
coding standards and guidelines.

21
Representative Coding
Standards
⚫ Rules for limiting the use of globals:
⚫ what types of data can be declared global
and what can not.
⚫ Naming conventions for
⚫ global variables,
⚫ local variables, and
⚫ constant identifiers.

22
Representative Coding Standards

⚫ Contents of headers for different modules:

⚫ The headers of different modules should
be standard for an organization.
⚫ The exact format for header information is
usually specified.

23
Representative Coding Standards

⚫ 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.

24
Representative Coding Standards
⚫ Error return conventions and exception handling
mechanisms.
⚫ the way error and exception conditions are
handled should be standard within an
organization.
⚫ For example, when different functions
encounter error conditions
⚫ should either return a 0 or 1 consistently.

25
Representative Coding Guidelines

⚫ Do not use too clever and difficult to

understand coding style.
⚫ Code should be easy to understand.

⚫ Many inexperienced engineers actually take

pride in writing cryptic and incomprehensible
code.

26
 Representative Coding Guidelines
⚫ Clever coding can obscure meaning of the
code:
⚫ hampers understanding.
⚫ makes later maintenance difficult.

⚫ Avoid obscure side effects.

27
 Representative Coding Guidelines
⚫ The side effects of a function call include:
⚫ modification of parameters passed by
reference,
⚫ modification of global variables,
⚫ I/O operations.

⚫ An obscure side effect is one that is not

obvious from a casual examination of the code.

28
Representative Coding Guidelines

⚫ Obscure side effects make it difficult to

understand a piece of code.
⚫ For example,
⚫ if a global variable is changed obscurely in
a called module, it becomes difficult for
anybody trying to understand the code.

29
Representative Coding Guidelines

⚫ Do not use an identifier (variable name) for

multiple purposes.
⚫ Programmers often use the same identifier
for multiple purposes.
⚫ For example, some programmers use a
temporary loop variable, also for storing
the final result.

30
Example use of a variable for
multiple purposes
⚫for(i=1;i<100;i++)
{…..}
i=2*p*q;
return(i);

31
Use of a variable for multiple
purposes
⚫ The rationale given by programmers for such
use:
⚫ memory efficiency:
⚫ e.g. three variables use up three memory
locations,
⚫ whereas the same variable used in three
different ways uses just one memory location.

32
Use of a variable for multiple
purposes
⚫ There are several things wrong with this
approach:
⚫ hence should be avoided.
⚫ Each variable should be given a name
indicating its purpose:
⚫ This is not possible if an identifier is used for
multiple purposes.

33
Use of a variable for multiple
purposes

⚫Leads to confusion and

annoyance, for anybody trying to
understand the code.
⚫ Also makes future maintenance
difficult.

34
Representative Coding Guidelines

⚫ Code should be well-documented.

⚫ Rules of thumb:
⚫ on the average there must be at least one comment
line, for every three source lines.
⚫ The length of any function should not exceed 10
source lines.

35
Representative Coding Guidelines

⚫ Lengthy functions:
⚫ usually are very difficult to understand
⚫ probably do too many different things.

36
Representative Coding Guidelines

⚫ Do not use goto statements.

⚫ Use of goto statements:
⚫ make a program unstructured
⚫ make it very difficult to understand.

37
Code Review Techniques
 Code Review Techniques

Code Walkthrough Code Inspection

Code Walk Through
Code Walk Through

⚫ An informal code analysis technique,

undertaken after the coding of a module is
complete.
⚫ A few members of the development team select
some test cases and simulate execution of the
code by hand using these test cases.

41
 Code Walk Through
⚫ Even though an informal technique, several
guidelines have evolved over the years making
this naive but useful analysis technique more
effective.

⚫ These guidelines are based on personal

experience, common sense, and several
subjective factors.

42
Code Walk Through
⚫ The guidelines should be considered as examples:
⚫ rather than accepted as rules to be applied dogmatically.

⚫ 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.

43
Code Walk Through
⚫ Discussion should focus on discovery of errors:
⚫ and not on how to fix the discovered errors.

⚫ To foster cooperation:
⚫ avoid the feeling among engineers that they are
being evaluated in the code walk through
meeting, managers should not attend the walk
through meetings.

44
Code Inspection
Code Inspection
⚫ In contrast to code walkthroughs,
⚫ code inspection aims mainly at discovery of
commonly made errors.
⚫ 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 walkthroughs.

46
Code Inspection
⚫ Good software development companies:
⚫ collect statistics of errors committed by their
engineers
⚫ identify the types of errors most frequently
committed.
⚫ A list of common errors:
⚫ can be used during code inspection to look out for
possible errors.

47
 Commonly made errors
⚫ Use of uninitialized variables.
⚫ Non terminating loops.
⚫ Array indices out of bounds.
⚫ Incompatible assignments.
⚫ Improper storage allocation and de-allocation.
⚫ Actual and formal parameter mismatch in procedure calls.
⚫ Jumps into loops.
⚫ Use of incorrect logical operators or incorrect precedence
among operators.
⚫ Improper modification of loop variables.
⚫ Comparison of equality of floating point values, etc.

48
Clean Room Testing
Clean room testing
⚫ Clean room testing was pioneered by IBM.

⚫ This type of testing relies heavily on walkthroughs,

inspection, and formal verification.

⚫ The programmers are not allowed to test any of their code by

executing the code other than doing some
syntax testing using a compiler.

⚫ The software development philosophy is based

on avoiding software defects by using a rigorous inspection
process. The objective of this software is zero-defect
software.
Thank You