UNIT 3 Coding
UNIT 3 Coding
Coding
Good software development organizations normally require their programmers to
adhere to some well-defined and standard style of coding called coding standards.
Most software development organizations formulate their own coding standards that
suit them most, and require their engineers to follow these standards rigorously. The
purpose of requiring all engineers of an organization to adhere to a standard style of
coding is the following:
• A coding standard gives a uniform appearance to the codes written by different
engineers.
• It enhances code understanding.
• It encourages good programming practices.
A coding standard lists several rules to be followed during coding, such as the
way variables are to be named, the way the code is to be laid out, error return
conventions, etc.
Avoid obscure side effects: The side effects of a function call include modification
of parameters passed by reference, modification of global variables, and I/O
operations. An obscure side effect is one that is not obvious from a casual
examination of the code. 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 or
some file I/O is performed which is difficult to infer from the function’s name and
header information, it becomes difficult foranybody trying to understand the code.
Do not use an identifier for multiple purposes: Programmers often use the same
identifier to denote several temporary entities. For example, some programmers use
a temporary loop variable for computing and a storing the final result. The rationale
that is usually given by these programmers for such multiple uses of variables is
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. However,
there are several things wrong with this approach and hence should be avoided.
Some of the problems caused by use of variables for multiple purposes as follows:
• Each variable should be given a descriptive name indicating its purpose.
This is not possible if an identifier is used for multiple purposes. Use of a variable for
multiple purposes can lead to confusion and make it difficult for somebody trying to
read and understand the code.
• Use of variables for multiple purposes usually makes future enhancements more
difficult.
The length of any function should not exceed 10 source lines: A function that is
very lengthy is usually very difficult to understand as it probably carries out many
different functions. For the same reason, lengthy functions are likely to have
disproportionately larger number of bugs.
Code review
Code review for a model is carried out after the module is successfully compiled and
the all the syntax errors have been eliminated. Code reviews are extremely cost-
effective strategies for reduction in coding errors and to produce high quality code.
Normally, two types of reviews are carried out on the code of a module.These two
types code review techniques are code inspection and code walk through.
Code Inspection
In contrast to code walk through, the aim of code inspection is to discover some
common types of errors caused due to oversight and improper programming. In
other words, 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. For instance, consider the classical error of writing a procedure that
modifies a formal parameter while the calling routine calls that procedure with a
constant actual parameter. It is more likely that such an error will be discovered by
looking for these kinds of mistakes in the code, rather than by simply hand simulating
execution of the procedure. In addition to the commonly made errors, adherence to
coding standards is also checked during code inspection. Good software
development companies collect statistics regarding different types of errors
commonly committed by their engineers and identify the type of errors most
frequently committed. Such a list of commonly committed errors can be used during
code inspection to look out for possible errors.
Following is a list of some classical programming errors which can be checked
during code inspection:
Use of uninitialized variables.
Jumps into loops.
Nonterminating loops.
Incompatible assignments.
Array indices out of bounds.
Improper storage allocation and deallocation.
Mismatches between actual and formal parameter in procedure calls.
Use of incorrect logical operators or incorrect precedence among operators.
Improper modification of loop variables.
Comparison of equally of floating point variables, etc.
The name ‘clean room’ was derived from the analogy with semi-conductor fabrication
units. In these units (clean rooms), defects are avoided by manufacturing in ultra-
clean atmosphere. In this kind of development, inspections to check the consistency
of the components with their specifications has replaced unit-testing.
This technique reportedly produces documentation and code that is more reliable
and maintainable than other development methods relying heavily on code
execution-based testing.
The clean room approach to software development is based on five characteristics:
• Formal specification: The software to be developed is formally specified. A state-
transition model which shows system responses to stimuli is used to express the
specification.
• Incremental development: The software is partitioned into increments which are
developed and validated separately using the clean room process. These increments
are specified, with customer input, at an early stage in the process.
• Structured programming: Only a limited number of control and data abstraction
constructs are used. The program development process is process of stepwise
refinement of the specification.
• Static verification: The developed software is statically verified using rigorous
software inspections. There is no unit or module testing process for code
components.