Scribd
Upload
10 views4 pages

Se Unit-4

The document outlines the coding and testing phases of software development, emphasizing the importance of coding standards and guidelines to ensure clarity and maintainability. It also discusses the significance of both internal and external documentation, which aids in understanding and using the software effectively. Additionally, it introduces Gunning’s fog index as a metric for measuring document readability.

Uploaded by

Hemanth Atla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views4 pages

Se Unit-4

The document outlines the coding and testing phases of software development, emphasizing the importance of coding standards and guidelines to ensure clarity and maintainability. It also discusses the significance of both internal and external documentation, which aids in understanding and using the software effectively. Additionally, it introduces Gunning’s fog index as a metric for measuring document readability.

Uploaded by

Hemanth Atla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

CODING & TESTING

Coding is undertaken once the design phase is complete and the design documents have
been successfully reviewed. After all the modules of a system have been coded and unit
tested, the integration and system testing phase is undertaken
Integration and testing of modules is carried out according to an integration plan. The
integration plan, according to which different modules are integrated together, During
each integration step, a number of modules are added to the partially integrated system
and the resultant system is tested.
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.

Coding Standards and Guidelines


Good software development organisations usually develop their own coding standards
and guidelines depending on what suits their organisation best and based on the specific
types of software they develop.
Representative coding standards
Rules for limiting the use of globals: These rules list what types of data can be declared
global and what cannot, with a view to limit the data that needs to be defined with global
scope.
Standard headers for different modules: The header of different modules should have
standard format and information for ease of understanding and maintenance. The
following is an example of header format that is being used in some companies:
Name of the module.
Date on which the module was created.
Author’s name.
Modification history.
Synopsis of the module.
Global variables accessed/modified by the module.

Naming conventions for global variables, local variables, and constant identifiers:
A popular naming convention is that variables are named using mixed case lettering.
Global variable names would always start with a capital letter (e.g., GlobalData) and
local variable names start with small letters (e.g., localData). Constant names should be
formed using capital letters only (e.g., CONSTDATA).
Conventions regarding error return values and exception handling mechanisms:
The way error conditions are reported by different functions in a program should be
standard within an organisation.
coding guidelines:
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.
Avoid obscure side effects: The side effects of a function call include modifications to
the 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
Do not use an identifier for multiple purposes: Programmers often use the same
identifier to denote several temporary entities. For example, some programmers make use
of a temporary loop variable for also computing and storing the final result. e.g., three
variables use up three memory locations, whereas when the same variable is used for
three different purposes, only one memory location is used
Length of any function should not exceed 10 source lines: A lengthy function is
usually very difficult to understand as it probably has a large number of variables and
carries out many different types of computations. For the same reason, lengthy functions
are likely to have disproportionately larger number of bugs.
Do not use GO TO statements: Use of GO TO statements makes a program
unstructured. This makes the program very difficult to understand, debug, and maintain.

SOFTWARE DOCUMENTATION
software is developed, in addition to the executable files and the source code, several
kinds of documents such as users’ manual, software requirements specification (SRS)
document, design document, test document, installation manual, etc., are developed as
part of the software engineering process. Good documents are helpful in the following
ways:
Good documents help enhance understandability of code.
As a result, the availability of good documents help to reduce the effort and time required
for maintenance.
Documents help the users to understand and effectively use the system.
Different types of software documents can broadly be classified into the following:
Internal documentation: These are provided in the source code itself.
External documentation: These are the supporting documents such as SRS document,
installation document, user manual, design document, and test document.

Internal Documentation
Internal documentation is the code comprehension features provided in the source code
itself. Internal documentation can be provided in the code in several forms. The important
types of internal documentation are the following:
Comments embedded in the source code.
Use of meaningful variable names.
Module and function headers.
Code indentation.
Code structuring (i.e., code decomposed into modules and functions).
Use of enumerated types.
Use of constant identifiers.
Use of user-defined data type

External Documentation
External documentation is provided through various types of supporting documents such
as users’ manual, software requirements specification document, design document, test
document, etc. A systematic software development style ensures that all these documents
are of good quality and are produced in an orderly fashion. An important feature that is
requierd of any good external documentation is consistency with the code. If the different
documents are not consistent, a lot of confusion is created for somebody trying to
understand the software. In other words, all the documents developed for a product
should be up-to-date and every change made to the code should be reflected in the
relevant external documents.
Gunning’s fog index
Gunning’s fog index (developed by Robert Gunning in 1952) is a metric that has been
designed to measure the readability of a document. The computed metric value (fog
index) of a document indicates the number of years of formal education that a person
should have, in order to be able to comfortably understand that document. The Gunning’s
fog index of a document D can be computed as follows: Observe that the fog index is
computed as the sum of two different factors.

The first factor computes the average number of words per sentence (total number of
words in the document divided by the total number of sentences). This factor therefore
accounts for the common observation that long sentences are difficult to understand. The
second factor measures the percentage of complex words in the document o f words that
can be independently pronounced. For example, the word “sentence” has three syllables
(“sen”, “ten”, and “ce”). Words having more than three syllables are complex words a

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy