Chapter 4: CODING

Introduction
Programming Principles & Guidelines
Coding process
Verification
Refactoring
Common Refactoring
Metrics
Classification of Metrics

1
 Introduction
 The goal of the coding or programming activity is to implement
the design in the best possible manner.
 Coding affects testing and maintenance profoundly
 The time spent in coding is a small percentage of the total
software cost, while testing & maintenance consume major
percentage.
 As testing and maintenance costs are high, the aim of coding
activity should be to write code that reduces these costs
 Hence, goal should not be to reduce coding cost, but testing and
maintenance cost, i.e. make the job of tester and maintainer
easier

2
 Programming Principles & Guidelines
 The main goal of the programmer is to write simple and easy to
read programs with few bugs in it.
 There are various programming principles that can help to write a
code that is easier to understand.
 Some of these are
Be aware of common programming errors
Use structured programming
Apply information hiding
Follow some coding practices
Practice coding standards

3
 Common Coding Errors
 Much of effort in developing software goes in identifying and
removing bugs/faults.
 There are various practices that can reduce the occurrence of bugs,
but regardless of the tools or methods we use, bugs are always
going to occur in programs.
 Common bugs which occur during coding directly or indirectly
manifest themselves to a larger damage to the running program

4
 Structured Programming
 The structured programming practice helps develop programs that
are easier to understand.
 The goal of structured programming is to simplify program
structure
 A program has a static structure which is the ordering of statements
in the code – and this is a linear ordering
 A program also has dynamic structure –order in which statements
are executed
 Correctness of a program must talk about the dynamic structure
 Hence, to show a program as correct, we must show that its
dynamic behavior is as expected
 The aim of structured programming is to write programs whose
dynamic structure is same as static structure

5
 Information Hiding
 Software solutions always contain data structures that hold
information
 Programs work on these data structures to perform the functions
they want
 In general only some operations are performed on the information,
i.e. the data is manipulated in a few ways only
 The information should be hidden; only operations on it should be
exposed (information hiding )
I.e. data structures are hidden behind the access functions, which
can be used by programs
 Information hiding reduces coupling
This practice is a key foundation of OO and components, and is
also widely used today

6
 Coding Standards
 Programmers spend more time reading code than writing code
 Readability is enhanced if some coding conventions are followed
by all
 Coding standards provide these guidelines for programmers
 Some Java coding conventions are
Naming conventions e.g. Const name, package name, Type
name, method name variable name
Commenting and layout e.g. single line and multiline comments
Layout guidelines e.g. Indentation guidelines

7
 Coding Process
 Coding starts when specifications for modules from design is
available
 Usually modules are assigned to programmers for coding
 In top-down development, top level modules are developed first; in
bottom-up lower levels modules are developed first.
 For coding, developers use different processes; Some of these are.
An Incremental Coding Process : most common
Test Driven Development: relatively new approach
Pair programming: key technique in extreme programming
methodology

8
 An Incremental Coding Process
 In this process
 A code is written for the currently assigned module, and when
done, unit testing is performed on it and the bugs found are fixed
 Then the code is checked in the project repository to make it
available to others in the project.
 Look at the figure on next page
 A better process for coding, that is often followed by experienced
developers – most common one
 Advantage
 with testing being done after every round of coding is to facilitate
debugging—an error found in some testing can be safely attributed
to code that was added since last successful testing.

9
10
 Test Driven Development (TDD)
 In TDD, a programmer first writes the test scripts, and then writes
the code to pass the tests.
 The whole process is done incrementally, with tests being written
based on the specifications and code being written to pass the tests.
 Is a relatively new approach, and is a part of the extreme
programming (XP)
 Ensures that all functionality is there is on test case design, not
coding
 Help ensure that all code is testable (advantages)
 Has possibility that special cases for which test cases are not
possible get left out (Disadvantage)

11
12
 Pair programming
 Also a coding process that has been proposed as key practice in XP
 Code is written by pair of programmers rather than individuals
The pair together design algorithms, data structures, strategies,
etc.
One person types the code, the other actively reviews what is
being typed
Errors are pointed out and together solutions are formulated
Roles are reversed periodically
 Advantage
PP has continuous code review, and reviews are known to be
effective
likely to result in better decisions being taken about the data
structures, algorithms, interfaces, logic, etc.
 Disadvantage
It may, however, result in loss of productivity
13 Ownership and accountability issues are also there
 Verification
 Once a programmer has written the code for a module, it has to be
verified before it is used by others.
 Here we discuss only verification of code written by a programmer.
 There are many different techniques; Some of these are
Code Inspections
Unit Testing
Static Analysis
Formal verification

14
 Verification techniques
 Code Inspection:
Involves reviewing source code with a group who ask questions
analyzing the program logic, analyzing the code with respect to a
checklist of historically common programming errors, and
analyzing its compliance with coding standards.
 Unit Testing
A software testing technique that focuses on exercising the
features of individual functions or modules in isolation.
 Static Analysis
Analysis of a program carried out without executing the program.
 There numerous tool supports
 Formal Verification
Use of various types of logic and mathematical methods to verify
the correctness of code - Used mostly in very critical situations
15
 Refactoring
 Coding often involves making changes to some existing code to
enhance functionality
 Code also changes when requirements change or when new
functionality is added.
 Due to the changes being done to modules, even if we started with a
good design, with time we often end up with code whose design is
not as good as it could be.
that is the design might deteriorates due to changes.
 Once design becomes too complex, making changes become much
harder and error prone and hence quality and productivity of
enhancements starts decreasing
 Refactoring is the technique to improve existing code and prevent
this design decay with time.
1
6
 Common Refactorings
 Clearly there are unlimited possibilities of how code can be
refactored to improve its design.
 For improving design, refactoring’s focus is either
Methods
classes, or
the class hierarchies
 Many refactorings have been proposed; new ones keep getting
added

1
7
 Common Refactorings…
 Improving Methods
 Extract/split Method
 Add/Remove parameter
 Improving Classes
 Move methods, field
 Extract/split classes
 Replace data values with object
 Improving Hierarchies
 Replace conditional with polymorphism
 Pull up Field/Method

18
 Metrics
 Metric is quantitative measure of degree to which a system,
component or process possesses a given attribute.
E.g., Number of errors found per person hours expended
 Why Software Metrics?
Determine the quality of the current product/process
Predict qualities of a product/process
Improve quality of a product/process
 Data collection is important for metrics computation
Decide on what Metrics are to be used
Decide on how to collect the data
Decide on tools to help in the collection
 Metrics computation is highly supported by CASE tool

1
9
 Classification of Metrics
 Three types of software metrics are product metrics, process metrics
and project metrics
 Product Metrics: reefers to all the deliverables
Focus has been on Code, but interested in all artifacts
Include complexity, performance, size, etc.
 Processes Metrics : Metrics that originates from activities related to
production of software
Process metrics used to improve on development and support
activities. E.g. process quality, timetable & productivity metrics
 Project Metrics: Includes
Cost, Schedule
Staffing and other Resources
Customer Satisfaction
Project metrics used to improve productivity, cost, etc.
 Project and Process metrics are often intertwined.
2
0
 Linearly independent path
 Concepts
A linearly independent path is a complete path which,
disregarding back tracking (such as loops), has an unique set of
decisions in a program.
A linearly independent path is any path through the program
that introduces at least one new edge that is not included in any
other linearly independent paths.
 Facts
If a path has one new node compared to all other linearly
independent paths, then the path is also a linearly independent
path. This is because any path having a new node automatically
implies that it has a new edge.
A path that is subpath of another path is not considered to be a

21
linearly independent path
 Information Flow
 Information flow is movement of data through a system
 local direct flow exists if either
 a module invokes a second module and passed information to it
 the invoked module returns a result to the caller
 local indirect flow
 if the invoked module returns information that is subsequently
passed to a second module.
 Global flow
 information flows from one module to another via global data
structure

2
2
 Object Oriented Metrics
 Object-oriented development of software provide many benefits
Reusability
Decomposition of problem into easily understood object
the aiding of future modifications.
 The rise in popularity of object oriented methods raises questions
about how we measure object oriented structures.
 Chidamber and Kemerer's metrics suite for OO Design is the
deepest research in OO metrics investigation.
 Object-Oriented metrics can be categorized as
Size Metrics
Coupling Metrics
Cohesion Metrics
Inheritance Metrics

23
 Object Oriented Metrics: Size Metrics
 Number of Methods per Class (NOM) - b/n 3 to 7
 Number of Attributes per Class (NOA) – b/n 2 to 5
For a class, NOM and NOA are count of the number of methods
and attributes respectively while for a package, this is a count of
the average number of methods and attributes per class of the
package. n

 Weighted Methods per Class (WMC) = 

i 1
ci

c is the complexity (e.g., volume, cyclomatic complexity, etc.)

i
of each method
 Class Size (CS):
 measured by summing number of operations (inherited, private,
public) and number of attributes (inherited, private, public)
 Response for a Class (RFC)
the number of local methods plus the number of methods called
by local methods. 24
 Object Oriented Metrics: Coupling Metrics
 Coupling between Objects (CBO)
Number of other classes to which it is coupled.
Two classes are coupled when methods declared in one class use
methods or instance variables by the other classes
 Data Abstraction Coupling(DAC)
Number of Abstract Data Types (user defined data types) in a class.
 Message Passing Coupling (MPC)
Number of send statements defined in a class.
If two different methods in class A access the same method the
same method in class B, then MPC = 2
Example: If a class called Book calles getData() and display() from
both Sales and Publication classes, then MPC of class Book is 4
 Coupling Factor (CoF) - measures the coupling between classes
excluding coupling due to inheritance.
25
 Object Oriented Metrics: Cohesion Metrics
 Lack of Cohesion Metrics (LCOM)
defined as the number of disjoint (that is nonintersecting ) sets of local
methods.
Consider a class C1 with n methods M1, M2…., Mn.
Let (Ii) = set of all instance variables used by method M i. There are n
such sets {I1},…….{In}.
Let P {(Ii, Ij ) | Ii Ij = 0} and Q = {((Ii, Ij ) | Ii Ij ≠ 0}
If all n sets {( I1},........ .(I n)} are ø then P= ø
LCOM = | P | - | Q |, if | P |> | Q |
= 0 otherwise
 Example
Consider a class C with three methods M1, M2 and M3. Let {I1} =
{a,b,c,d,e} and {I2} = {a,b,e} and {I3} = {x,y,z}. {I1} {I2} is non-empty,
but {I1} {I3} and {I2} {I3} are null sets.
LCOM is the (number of null-intersections - number of non-empty
intersections), which in this case is 1.
 Object Oriented Metrics: Inheritance Metrics
 Depth of Inheritance Tree (DIT)
the maximum length from a node to the root (base class), in
hierarchy of classes.
It is measured by the number of ancestor classes
In case of multiple inheritance take the maximum length from
the node to the root of the tree
 Number of Children (NOC)
the number of subclasses immediately subordinate to a class
 Number of Operations Overridden (NOO)
is number of methods overridden
 Number of Operations Added (NOA)
The number of operations newly added by a subclass

2
7
 Tool support for metrics
 There are many tools to compute aforementioned metrics
 McCabe & Associates ( founded by Tom McCabe, Sr.)
The Visual Quality ToolSet
The Visual Testing ToolSet
The Visual Reengineering ToolSet
 Metrics calculated
McCabe Cyclomatic Complexity
McCabe Essential Complexity
Module Design Complexity
Integration Complexity
Lines of Code
Halstead

2
8