Coding

(Lecture 8)

Dr. R. Mall

1
 Coding Phase
 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
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.
3
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.
4
 Coding Standards
 Good software development
organizations require their
programmers to:
 adhere to some standard style
of coding
 called coding standards.

5
 Coding Standards
 Many software development
organizations:
 formulate their own coding
standards that suits them most,
 require their engineers to follow

these standards rigorously.

6
 Coding Standards
 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.
7
 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.

8
 Coding guidelines
 Provide general suggestions
regarding coding style to be
followed:
 leave actual implementation of
the guidelines:
 to the discretion of the
individual engineers.
9
Code inspection and code
walk throughs
 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.

10
Code inspection and code
walk throughs
 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.

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

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

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

14
 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.
15
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.

16
 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.
17
 Representative Coding Guidelines
 Clever coding can obscure meaning
of the code:
 hampers understanding.
makes later maintenance difficult.


 Avoid obscure side effects.

18
 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:
 one that is not obvious from a casual
examination of the code.
19
 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.

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

21
Example use of a variable for
multiple purposes

 for(i=1;i<100;i++)
{…..}
i=2*p*q;
return(i);

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

23
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.
24
Use of a variable for multiple
purposes

 Leads to confusion and

annoyance
 for anybody trying to
understand the code.
 Also makes future

maintenance difficult.
25
 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.

26
Representative Coding Guidelines

 Lengthy functions:
 usually very difficult to
understand
 probably do too many different

things.

27
Representative Coding Guidelines

 Do not use goto statements.

 Use of goto statements:

 make a program unstructured

 make it very difficult to

understand.

28
 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:
 simulate execution of the code by
hand using these test cases.
29
 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.

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

31
 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.
32
 Code Inspection
 In contrast to code walk throughs,
 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 walk throughs.

33
 Code Inspection
 For instance, consider:
 classical error of writing a procedure that
modifies a formal parameter
 while the calling routine calls the procedure
with a constant actual parameter.
 It is more likely that such an error will
be discovered:
 by looking for this kind of mistakes in the
code,
 rather than by simply hand simulating
execution of the procedure.

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

35
 Commonly made errors
 Use of uninitialized variables.
 Nonterminating loops.
 Array indices out of bounds.
 Incompatible assignments.
 Improper storage allocation and deallocation.
 Actual and formal parameter mismatch in
procedure calls.
 Jumps into loops.

36
 Code Inspection
 Use of incorrect logical operators
 or incorrect precedence among operators.
 Improper modification of loop variables.
 Comparison of equality of floating point
values, etc.
 Also during code inspection,
 adherence to coding standards is checked.

37
 Software Documentation
 When developing a software product we develop
various kinds of documents :
 In addition to executable files and the source code:
 users' manual,
 software requirements specification (SRS) document,
 design document, test document,
 installation manual, etc.
 All these documents are a vital part of good
software development practice.

38
 Software Documentation
 Good documents enhance
understandability and maintainability of
a software product.
 Different types of software documents
can be classified into:
 internal documentation,
 external documentation (supporting
documents).

39
 Internal Documentation
 Internal documentation:
 documentation provided in the
source code itself.
 External documentation:
 documentation other than those
present in the source code.

40
 Internal Documentation
 Internal documentation provided through:
 use of meaningful variable names,
 code indentation,
 code structuring,
 use of enumerated types and constant
identifiers,
 use of user-defined data types, etc.
 module headers and comments

41
 Internal Documentation
 Good software development
organizations:
 ensure good internal documentation
 through coding standards and coding

guidelines.
 Example of unhelpful documentation:
 a = 10; /* a made 10 */

42
Internal Documentation
 Careful experimentation
suggests:
 meaningful variable names
is the most useful internal
documentation.

43
 External Documentation
 Users' manual,
 Software requirements specification

document,
 Design document,

 Test documents,

 Installation instructions, etc.

44
 External Documentation
 A systematic software development
style ensures:
 all external documents are produced
in an orderly fashion.
 An important feature of good
documentation is consistency.

45
 External Documentation
 Unless all documents are consistent with
each other,
 a lot of confusion is created for somebody
trying to understand the product.
 All the documents for a product should
be up-to-date:
 Even a few out-of-date documents can
create severe confusion.
46
 Textual Documents
 Readability is an important attribute of
textual documents.
 Readability determines understandability
 hence determines maintainability.
 A well-known readability measure of text
documents:
 Gunning’s Fog Index.

47
 Gunning’s Fog Index
Number of Words Percentage of
F=0.4 ` + words of 3 or
Number of Sentences more syllables

 F corresponds to the number of years

of schooling to easily understand the
document.

48
 Gunning’s Fog Index
 A document is easy to
understand if:
 all sentences are small
 use only 4 to 5 words each
 small number of characters
used per word:
 normally not exceeding five or
six characters.
49
Summary
 Widgets are the building blocks of
user interface design.
 To develop a modern GUI:

 put together the widgets you require

 stitch them together.

 makes user interface development

easy.
50
Summary
 We discussed some standard widgets:
 pull down menus
 pop up menus
 labels
 dialog boxes
 radio buttons
 push buttons
 containers

51
Summary
 Coding standards:
 enforce good coding practice
 Coding guidelines:
 suggestions to programmers
 exact implementation depends on

discretion of the programmers.

52
Summary
 It is necessary to
adequately document a
software product:
 Helps in understanding the
product
 Helps in maintenance

53
Summary
 Documentation
 Internal
 External
 Internal documentation
 provided in the source code itself.
 Comprehensibility of text
documents:
 mesured using Gunning’s Fog
index.
54