Chapter -6

Coding
 Coding
Coding is one of the important, critical and
interesting phase of software development life
cycle.
The goal of the coding or programming activity
is to implement the design in the best possible
manner.
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
 Coding…
Code is read a lot more:
Coders themselves read the code
many times for debugging,
extending etc.
Maintainers spend a lot of effort
reading and understanding code
Other developers read code when
they add to existing code

3
 Programming Principles &
Guidelines
The main goal of the programmer is to write
simple and easy to read programs with few bugs
in it.
Of course, the programmer has to develop it
quickly to keep productivity high
There are various programming principles that
can help write code that is easier to understand
(and test…)
Good programming (producing correct and
simple programs) is a practice independent of
the target programming language,
 Although well-structured programming

4
languages make the programmer's job simpler.
 Common Coding Errors
Much of effort in developing software goes
in identifying and removing
bugs/errors/defects.
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
A memory leak
 NULL Dereferencing
 Accessing uninitialized memory
 Lack of Unique Addresses
 Synchronization Errors
 Buffer overflow

Other common type of errors

6
 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
E.g. on a bank’s ledger, only debit, credit, check current
balance etc are done
Information hiding – the information should be
hidden; only operations on it should be exposed
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,
7
and is also widely used today
 Some Programming Practices
Control constructs: Use only a few
structured constructs (rather than using a
large no of constructs)
Goto: Use them sparingly, and only when
the alternatives are worse
Information hiding: Use information hiding
User-defined types: use these to make
the programs easier to read
Nesting: Avoid heavy nesting of if-then-
else; if disjoint nesting can be avoided
Module size: Should not be too large –
8
generally means low cohesion
 Some Programming
Practices…
Module interface: make it simple
Robustness: Handle exceptional situations
Side effects: Avoid them, where possible
Empty catch block: always have some
default action rather than empty
Empty if, while: bad practice
Read return: should be checked for
robustness
Return from finally Block: should not
return from finally
Correlated parameters: Should check for
compatibility

9
 Coding Standards
Programmers spend more time reading
code than writing code
They read their own code as well as
other programmers code
Readability is enhanced if some coding
conventions are followed by all
Coding standards provide these
guidelines for programmers
Generally are regarding naming, file
organization, statements/declarations, …
Some Java conventions discussed here
10
 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; We now look at some
processes that developers use during
coding, or that have been suggested.
11
 An Incremental Coding Process
The process followed by many developers is;
 write the code for the currently assigned module,
and when done,
perform unit testing on it and fix the bugs found.
Then the code is checked in the project repository
to make it available to others in the project.
It is better to do this incrementally – write
code for part of functionality, then test it and
fix it, then proceed by adding further
functionality to the code, which is then
tested again.
I.e. code is built for a module by coders
incrementally
12
13
 Test Driven Development
This coding process changes the order
of activities in coding
In test driven development,
programmer first writes the test scripts
and then writes the code to pass the
test cases in the script
This is done incrementally
Is a relatively new approach, and is a
part of the extreme programming (XP)
In TDD, you write just enough code to
pass the test
14
 Test Driven Development …
Responsibility to ensure that all functionality
is there is on test case design, not coding.
Help ensure that all code is testable
Focus shifts to how code will be used as test
cases are written first
Helps validate user interfaces specified in the design
Focuses on usage of code
Functionality prioritization happens naturally
Has possibility that special cases for which
test cases are not possible get left out
Code improvement through refactoring will
be needed to avoid getting a messy code
15
16
 Pair Programming
Pair programming is also a coding
process that has been proposed as a key
technique in extreme programming (XP)
methodology
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
17 Roles are reversed periodically
 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;
key ones – unit testing, inspection,
and program checking
Program checking can also be used
at the system level

18
 Code Inspections
The inspection process can be applied to
code with great effectiveness
Inspections are usually held when code has
compiled and a few tests passed
Inspection team focuses on finding defects
and bugs in code
Checklists are generally used to focus the
attention on defects
Some items in a checklist
Do all pointers point to something
Are all variables and pointers initialized
Are all array indexes within bounds
Will all loops always terminate
Any security flaws
Is input data being checked
19 Obvious inefficiencies
 Code inspections…
Are very effective and are widely
used in industry (many require all
critical code segments to be
inspected)
Code inspection is expensive; for non
critical code one person inspection
may be used
Code reading is self inspection

20
 Unit Testing
Is testing, except the focus is the module a
programmer has written
Most often unit testing is done by the
programmer himself
Unit testing requires generating test cases for the
module (most difficult and challenging task)– will
be discussed in testing
There are frameworks like Junit that can be used
for testing Java classes
If incremental coding is being done, then
complete unit testing needs to be automated
Otherwise, repeatedly doing unit testing will not
be possible as programmer adds some code every
time
I.e. unit testing is a script that returns pass/fail
21
 Static Analysis
These are tools to analyze program
sources and check for problems
Static analyzer cannot find all bugs
and often cannot be sure of the bugs
it finds as it is not executing the code
So there is noise in their output
Many different tools available that
use different techniques
They are effective in finding bugs like
memory leak, dead code, dangling
pointers,..
22
 Formal Verification
These approaches aim to prove the
correctness of the program
i.e. the program implements its
specifications
Require formal specifications for the
program, as well as rules to interpret the
program
Was an active area of research; scalability
issues became the bottleneck
Used mostly in very critical situations, as
an additional approach
23
 Proving Correctness
Ultimate goal of verification techniques is to
make programs correct by removing errors
Proving a program as correct while
developing it may result in more reliable
program that can be proved more easily
Any proof technique must begin with a
formal specification of the program
Stating the goal of the program is not
sufficient
Input conditions in which the program is to
be invoked (pre conditions) and expected
valid results (post conditions) should also
24 be mentioned.
 Axiomatic Approach
Axiomatic method (Floyd-Hoare proof method)
is one method for proving correctness
Goal is to take the program and construct a
sequence of assertions, and the rules and
axioms about statements and operations in
the program
Basic assertion about a program in Hoare’s
notation is
P{S}Q, where,
P – precondition,
Q – post condition,
S- program segment
These assertions are about the values taken
by the variables in the program before and
after its execution
25
 Summary
Goal of coding is to convert a design
into easy to read code with few bugs
Good programming practices like
structured programming,
information hiding, etc can help
There are many methods to verify
the code of a module – unit testing
and inspections are most commonly
used
26
27