CODING
Coding- The objective of the coding phase is to transform the design of a system into code in a
high level language and then to unit test this code. The programmers adhere to standard and well
defined style of coding which they call their coding standard. The main advantages of adhering
to a standard style of coding are as follows:
A coding standard gives uniform appearances to the code written by different
engineers
It facilitates code of understanding.
Promotes good programming practices.
For implementing our design into a code, we require a good high level language. A programming
language should have the following features:
Characteristics of a Programming Language
Readability: A good high-level language will allow programs to be written in some ways
that resemble a quite-English description of the underlying algorithms. If care is taken,
the coding may be done in a way that is essentially self-documenting.
Portability: High-level languages, being essentially machine independent, should be able
to develop portable software.
Generality: Most high-level languages allow the writing of a wide variety of programs,
thus relieving the programmer of the need to become expert in many diverse languages.
Brevity: Language should have the ability to implement the algorithm with less amount
of code. Programs expressed in high-level languages are often considerably shorter than
their low-level equivalents.
Error checking: Being human, a programmer is likely to make many mistakes in the
development of a computer program. Many high-level languages enforce a great deal of
error checking both at compile-time and at run-time.
Cost: The ultimate cost of a programming language is a function of many of its
characteristics.
, Familiar notation: A language should have familiar notation, so it can be understood by
most of the programmers.
Quick translation: It should admit quick translation.
Efficiency: It should permit the generation of efficient object code.
Modularity: It is desirable that programs can be developed in the language as a
collection of separately compiled modules, with appropriate mechanisms for ensuring
self-consistency between these modules.
Widely available: Language should be widely available and it should be possible to
provide translators for all the major machines and for all the major operating systems.
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.
Coding standards and guidelines
Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they develop.
The following are some representative coding standards.
1. Rules for limiting the use of global: These rules list what types of data can be declared
global and what cannot.
2. Contents of the headers preceding codes for different modules: The information
contained in the headers of different modules should be standard for an organization. The
exact format in which the header information is organized in the header can also be
specified. The following are some standard 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.
, 3. Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always start with a capital
letter, local variable names are made of small letters, and constant names are always
capital letters.
4. Error return conventions and exception handling mechanisms: The way error
conditions are reported by different functions in a program are handled should be
standard within an organization. For example, different functions while encountering an
error condition should either return a 0 or 1 consistently.
The following are some representative coding guidelines recommended by many software
development organizations.
1. Do not use a coding style that is too clever or too difficult to understand: Code
should be easy to understand. Many inexperienced engineers actually take pride in
writing cryptic and incomprehensible code. Clever coding can obscure meaning of the
code and hamper understanding. It also makes maintenance difficult.
2. 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 for anybody trying to understand the code.
3. 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.
4. The code should be well-documented: As a rule of thumb, there must be at least one
comment line on the average for every three-source line.
5. 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.
6. Do not use goto statements: Use of goto statements makes a program unstructured and
very difficult to understand.
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 Walk Throughs
Code walk through is an informal code analysis technique. In this technique, after a module has
been coded, successfully compiled and all syntax errors eliminated. A few members of the
development team are given the code few days before the walk through meeting to read and
understand code. Each member selects some test cases and simulates execution of the code by
hand (i.e. trace execution through each statement and function execution). The main objectives
of the walk through are to discover the algorithmic and logical errors in the code. The members
note down their findings to discuss these in a walk through meeting where the coder of the
module is present. Even though a code walk through is an informal analysis technique, several
guidelines have evolved over the years for making this naïve but useful analysis technique more
effective. Of course, these guidelines are based on personal experience, common sense, and
several subjective factors. Therefore, these guidelines should be considered as examples rather
than accepted as rules to be applied dogmatically. Some of these guidelines are the following:
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.
Discussion should focus on discovery of errors and not on how to fix the discovered
errors.
Coding- The objective of the coding phase is to transform the design of a system into code in a
high level language and then to unit test this code. The programmers adhere to standard and well
defined style of coding which they call their coding standard. The main advantages of adhering
to a standard style of coding are as follows:
A coding standard gives uniform appearances to the code written by different
engineers
It facilitates code of understanding.
Promotes good programming practices.
For implementing our design into a code, we require a good high level language. A programming
language should have the following features:
Characteristics of a Programming Language
Readability: A good high-level language will allow programs to be written in some ways
that resemble a quite-English description of the underlying algorithms. If care is taken,
the coding may be done in a way that is essentially self-documenting.
Portability: High-level languages, being essentially machine independent, should be able
to develop portable software.
Generality: Most high-level languages allow the writing of a wide variety of programs,
thus relieving the programmer of the need to become expert in many diverse languages.
Brevity: Language should have the ability to implement the algorithm with less amount
of code. Programs expressed in high-level languages are often considerably shorter than
their low-level equivalents.
Error checking: Being human, a programmer is likely to make many mistakes in the
development of a computer program. Many high-level languages enforce a great deal of
error checking both at compile-time and at run-time.
Cost: The ultimate cost of a programming language is a function of many of its
characteristics.
, Familiar notation: A language should have familiar notation, so it can be understood by
most of the programmers.
Quick translation: It should admit quick translation.
Efficiency: It should permit the generation of efficient object code.
Modularity: It is desirable that programs can be developed in the language as a
collection of separately compiled modules, with appropriate mechanisms for ensuring
self-consistency between these modules.
Widely available: Language should be widely available and it should be possible to
provide translators for all the major machines and for all the major operating systems.
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.
Coding standards and guidelines
Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they develop.
The following are some representative coding standards.
1. Rules for limiting the use of global: These rules list what types of data can be declared
global and what cannot.
2. Contents of the headers preceding codes for different modules: The information
contained in the headers of different modules should be standard for an organization. The
exact format in which the header information is organized in the header can also be
specified. The following are some standard 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.
, 3. Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always start with a capital
letter, local variable names are made of small letters, and constant names are always
capital letters.
4. Error return conventions and exception handling mechanisms: The way error
conditions are reported by different functions in a program are handled should be
standard within an organization. For example, different functions while encountering an
error condition should either return a 0 or 1 consistently.
The following are some representative coding guidelines recommended by many software
development organizations.
1. Do not use a coding style that is too clever or too difficult to understand: Code
should be easy to understand. Many inexperienced engineers actually take pride in
writing cryptic and incomprehensible code. Clever coding can obscure meaning of the
code and hamper understanding. It also makes maintenance difficult.
2. 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 for anybody trying to understand the code.
3. 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.
4. The code should be well-documented: As a rule of thumb, there must be at least one
comment line on the average for every three-source line.
5. 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.
6. Do not use goto statements: Use of goto statements makes a program unstructured and
very difficult to understand.
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 Walk Throughs
Code walk through is an informal code analysis technique. In this technique, after a module has
been coded, successfully compiled and all syntax errors eliminated. A few members of the
development team are given the code few days before the walk through meeting to read and
understand code. Each member selects some test cases and simulates execution of the code by
hand (i.e. trace execution through each statement and function execution). The main objectives
of the walk through are to discover the algorithmic and logical errors in the code. The members
note down their findings to discuss these in a walk through meeting where the coder of the
module is present. Even though a code walk through is an informal analysis technique, several
guidelines have evolved over the years for making this naïve but useful analysis technique more
effective. Of course, these guidelines are based on personal experience, common sense, and
several subjective factors. Therefore, these guidelines should be considered as examples rather
than accepted as rules to be applied dogmatically. Some of these guidelines are the following:
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.
Discussion should focus on discovery of errors and not on how to fix the discovered
errors.
