Structured Coding Techniques

• The Objective of the coding phase is to code

from the design document prepared after the
design phase through a high-level language
and then to unit test this code.
• software development organizations want
their programmers to maintain to some well-
defined and standard style of coding called
coding standards
 Coding Standards
• Many software development
organizations:
–formulate their own coding standards
that suits them most,
–require their engineers to follow
these standards rigorously.

3
 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.
4
 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,
• Error return conventions,etc.
5
Representative coding standards
– Rules for limiting the use of globals
– Standard headers for different modules
– Naming conventions
– Conventions regarding error return
 Coding guidelines
• Provide general suggestions
regarding coding style to be
followed:
–leave actual implementation of
the guidelines:
• to the discretion of the individual
engineers.
7
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.

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

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

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

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

13
 Representative Coding Guidelines
• Clever coding can obscure meaning of
the code:
– hampers understanding.
–makes later maintenance difficult.
• Avoid obscure side effects.

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

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

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

17
 Example use of a variable for
multiple purposes

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

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

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

20
Use of a variable for multiple purposes

• Leads to confusion and annoyance

–for anybody trying to understand
the code.
–Also makes future maintenance
difficult.

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

22
 Representative Coding Guidelines
• Lengthy functions:
–usually very difficult to understand
–probably do too many different
things.

23
 Representative Coding Guidelines
• Do not use goto statements.
• Use of goto statements:
–make a program unstructured
–make it very difficult to understand.

24
 Code Review
• Is a very effective technique to remove defects
from source code
• More cost effective than testing
• Is under taken after the module successfully
compiles
• Designed to detect logical, algorithmic,
programming errors
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.

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

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

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

29
 Code Walk Through
• The guidelines should be considered as
examples
• 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.

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

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

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

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

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

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

37
 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).

38
 Internal Documentation
• Internal documentation:
–documentation provided in the source
code itself.
• External documentation:
–documentation other than those
present in the source code.

39
 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

40
 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 */
41
 Internal Documentation
• Careful experimentation suggests:
–meaningful variable names
is the most useful internal
documentation.

42
 External Documentation
• Users' manual,
• Software requirements specification
document,
• Design document,
• Test documents,
• Installation instructions, etc.

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

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

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

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

• F corresponds to the number of years of

schooling to easily understand the
document.

47
 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.
48