Chapter 5: Coding

Tadele M.
Contents
 Introduction
 Programming Principles & Guidelines
 Coding process
 Verification
 Refactoring
 An example
 Bad Smells
 Common Refactoring
 Metrics
 Classification of Metrics

2
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
3
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
write code that is easier to understand (and test…).
 Some of these are
 Be aware of common programming errors
 Use structured programming
 Apply information hiding
 Follow some coding practices
 Practice coding standards

4
Common Coding Errors
 Much of effort in developing software goes in identifying and
removing bugs.
 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
 List of common coding errors can help a programmer avoid
them:

5
Common Coding Errors…
 Syntax errors
 Missing Parenthesis (}), semicolon(;)
 Printing the value of variable without declaring i
 Runtime Errors
 Division by Zero

int a = 5;
cout << a / 0;
int arr[5] = { 20, 30, 40, 50, 60 };
arr[2] = 40;
 Array index out of bounds arr[5] = 70;

 Off by one errors: (one too few or one too many times).
 Freeing an already freed resource for (int i = 0; i < 10; i++)

6
Verification
 Once a programmer has written the code for a module,
it has to be verified before it is used by others.
 There are many different techniques; Some of these are
 Code Inspections
 Unit Testing
 Static Analysis
 Formal verification

7
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
8 correctness of code - Used mostly in very critical situations
Refactoring: Ugly Code That Does Everything

9 Networking equivalent
Refactoring: Ugly Code That Does Everything
 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
1
0
prevent this design decay with time.
Refactoring…
 It is done during coding, but the purpose is not to add
new features or to fix bugs but to improve design.
 That is internal structure of software changes while external
behavior remains the same.
 Basic objective of refactoring is to improve design
embodied in code; but is not same as improving design
during the design process.
 To improve the design, principles of good design are
applicable.
 Refactoring tries to achieve one or more of the following
 Reduce coupling, Increase cohesion, Improve application of
open-closed principle
1
1
Refactoring…
 The main risk of refactoring is that existing working
code may "break“ due to the changes being made.
 To mitigate the risk, two golden rules are:
 Refactor in small steps.
 Have automated test scripts available to test existing
functionality.
Open Browser To Login Page
Input Username Abebe
Input password 12345
Submit Credentials

1
2
Bad Smells
 When can we say refactoring is needed?
 “Bad smells” are easy to spot signs in code which can indicate need for
refactoring.
 Symptoms in the source code of a program that possibly indicate a
deeper problem. … usually not bugs... not technically incorrect and
don't currently prevent the program from functioning.
 Instead, they indicate weaknesses in design that may be slowing down
development or increasing the risk of bugs or failures in the future.”
 Some of these bad smells
 Duplicate code
 Long method
 Long class
 Long parameter list void print(String documentToPrint, String papersize, int
 Dead Code pagefrom, int pageTo, float marginLeft, float marginRight,
float marginTop, float marginBottom ) { }
 Excessive comments
1
3
Common Refactorings…
 Improving Methods
 Extract/split Method
 Add/Remove parameter
 Improving Classes
 Move methods, field
 Extract/split classes
 Replace data values with object

14
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
 Identify areas of improvement
 Predict qualities of a product/process
 Improve quality of a product/process

1
5
Classification of Metrics
 Three types of software metrics are product metrics,
process metrics and project metrics
 Product Metrics: refers to all the deliverables
 Focus has been on Code, but interested in all artifacts
 Include size and complexity, performance, 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. efficiency of fault detection
 Project Metrics: used by the project manager to check the project's
progress.
 Cost, Schedule
 Staffing and other Resources
1  Customer Satisfaction
6
Product Metrics
 Product metrics can be :
 Size Metrics
 Line of code (LOC), Function Point (FP), etc
 Cyclomatic Complexity metrics
 McCabe’s cyclomatic complexity, Information Flow
 Halstead’s Product Metrics
 Program Vocabulary, Program Length, Program Volume
 Quality Metrics
 Correctness Metrics, Maintainability Metrics, integrity
metrics, Usability Metrics

1
7
Size Metrics
 LOC or KLOC
 non-commented, non blank lines
 Generally only new or modified lines are counted
 Easy to use and compute
 Bad software design may cause an excessive line of code
 Language & programmer dependent
•Quality = Errors per KLOC
•Cost = $ per KLOC
Size Metrics…

19
Size Metrics…
 The function point is a "unit of measurement" to express the
amount of business functionality a product provides to a user.
 counting the number and types of functions used in the
applications.
 Function Point
 used to assess the software size
 Started by Allan Albrecht of IBM in 1979
 Function Point does provide some advantages over line of code
 language independent
 don’t need the actual lines of code to do the counting

2
0
McCabe’s Cyclomatic Complexity metrics
 Numerous metrics have been proposed for measuring program
complexity
 McCabe’s metrics are based on a control flow representation of
the program.
 A program graph is used to depict control flow.
 Nodes represent processing tasks/statements
 Edges represent control flow between nodes
 Control Flow graph notations
Sequence
While

If-then-else Until

2
1
Cyclomatic Complexity
• Cyclomatic Complexity shows set of linearly independent
paths [V(G)] through the graph
• This is same as the number of linearly independent cycles in the
graph.
• It is calculated using one of the following formula
• V(G) = E – N + 2
• E is the number of flow graph edges
• N is the number of nodes
• V(G) = d + 1
• d is the number decision nodes
• V(G) = region + 1
• Region is enclosed regions in the program
2
2
Example 1
Draw Flow graph for the following code and
determine V(G)
1 if A = 10 then
2 if B > C
3 A = B
4 else A = C
5 endif
6 endif
7 print A, B, C
e = 8, n = 7
Then,
V(G) = 8 – 7 + 2 = 3
V(G) = 2 + 1 = 3
Paths: 1,6,7
1,2,3,5,6,7 Flowcharts
1,2,4,5,6,7
Example 2
Draw Flow graph for the following code and
determine V(G)
i = 0; 1
1
while (i<n-1) do
2
j = i + 1;
2
while (j<n) do
3
3 --if A[i]<A[j] then
4 swap(A[i], A[j]);
5 end do; 7 4 5

6 i=i+1;
7 end do; 6
2
Find out all linearly independent paths of
4 the graph
Flow Graph and Computing V(G)

1
e = 9, n = 7
Then,
2
V(G) = 9 – 7 + 2 = 4
V(G) = 3 + 1 = 4
3 Basis Set
1, 7
7 4 5 1, 2, 6, 1, 7
1, 2, 3, 4, 5, 2, 6, 1, 7
1, 2, 3, 5, 2, 6, 1, 7
6

2
5
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 linearly
26
independent path
Exercise 1

1. public static void sort(int x []) { 2

2. for (int i=0; i < x.length-1; i++) {
3. for (int j=i+1;j<x.length;j++){ 3
4. if (x[i] > x[j]) {
5. int save=x[i]; 4

6. x[i]=x[j];
7. x[j]=save; 5

8. }
9. } 6 11

10. }
7
11. }

Find out all linearly independent paths 9

of the graph
2 10
7