Coding

Coding is the process of transforming the design of a system into a computer

language format. This coding phase of software development is concerned with
translating design specifications into the source code. It is necessary to write
source code & internal documentation so that conformance of the code to its
specification can be easily verified.

Coding is done by the coder or programmers who are independent people than
the designer. The goal is not to reduce the effort and cost of the coding phase,
but to cut to the cost of a later stage. The cost of testing and maintenance can be
significantly reduced with efficient coding.

Goals of Coding
1. To translate the design of the system into a computer language
format: The coding is the process of transforming the design of a system
into a computer language format, which can be executed by a computer
and that perform tasks as specified by the design of operation during the
design phase.
2. To reduce the cost of later phases: The cost of testing and maintenance
can be significantly reduced with efficient coding.
3. Making the program more readable: Program should be easy to read and
understand. It increases code understanding, having readability and
understandability as a clear objective of the coding activity can itself help
in producing more maintainable software.

For implementing our design into code, we require a high-level functional

language. A programming language should have the following characteristics:

Characteristics of Programming Language

Readability: A good high-level language will allow programs to be written in
some methods that resemble a quite-English description of the underlying
functions. The coding may be done in an essentially self-documenting way.

Portability: High-level languages, being virtually machine-independent, should

be easy to develop portable software.

Generality: Most high-level languages allow the writing of a vast collection of

programs, thus relieving the programmer of the need to develop into an expert
in many diverse languages.
Brevity: Language should have the ability to implement the algorithm with less
code. Programs mean in high-level languages are often significantly shorter than
their low-level equivalents.

Error checking: A programmer is likely to make many errors in the development

of a computer program. Many high-level languages invoke a lot of bugs checking
both at compile-time and run-time.

Cost: The ultimate cost of a programming language is a task of many of its

characteristics.

Quick translation: It should permit quick translation.

Efficiency: It should authorize the creation of efficient object code.

Modularity: It is desirable that programs can be developed in the language as

several separately compiled modules, with the appropriate structure for ensuring
self-consistency among these modules.

Widely available: Language should be widely available, and it should be feasible

to provide translators for all the major machines and all the primary 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 Guidelines
General coding guidelines provide the programmer with a set of the best
methods which can be used to make programs more comfortable to read and
maintain. Most of the examples use the C language syntax, but the guidelines can
be tested in all languages.

The following are some representative coding guidelines recommended by many

software development organizations.
1. Line Length: It is considered a good practice to keep the length of source code
lines at or below 80 characters. Lines longer than this may not be visible properly
on some terminals and tools. Some printers will truncate longer than 80 columns.

2. Spacing: The appropriate use of spaces within a line of code can improve
readability.

Example:

Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);

Better: cost = price + ( price * sales_tax )

fprintf (stdout,"The total cost is %5.2f\n",cost);

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

4. The length of any function should not exceed 10 source lines: A very lengthy
function is generally very difficult to understand as it possibly carries out many
various functions. For the same reason, lengthy functions are possible to have a
disproportionately larger number of bugs.

5. Do not use goto statements: Use of goto statements makes a program

unstructured and very tough to understand.
6. Inline Comments: Inline comments promote readability.

7. Error Messages: Error handling is an essential aspect of computer

programming. This does not only include adding the necessary logic to test for
and handle errors but also involves making error messages meaningful.

Structured Programming
In structured programming, we sub-divide the whole program into small modules
so that the program becomes easy to understand. The purpose of structured
programming is to linearize control flow through a computer program so that the
execution sequence follows the sequence in which the code is written. The
dynamic structure of the program then resembles the static structure of the
program. This enhances the readability, testability, and modifiability of the
program. This linear flow of control can be managed by restricting the set of
allowed applications construct to a single entry, single exit formats.

Why we use Structured Programming?

We use structured programming because it allows the programmer to
understand the program easily. If a program consists of thousands of instructions
and an error occurs then it is complicated to find that error in the whole program,
but in structured programming, we can easily detect the error and then go to that
location and correct it. This saves a lot of time.

Code Block
Sequence

Alternation
Iteration
Nested Structures
Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of
objects (i.e., entities). The state is distributed among the objects, and each object
handles its state data. For example, in Library Automation Software, each library
representative may be a separate object with its data and functions to operate
on these data. The tasks defined for one purpose cannot refer to or change data
of other objects. Objects have their internal data which represent their state.
Similar objects create a class. In other words, each object is a member of some
class. Classes may inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects.
For example, people, banks, companies, and users are considered as
objects. Every entity has some attributes associated with it and has some
methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an
instance of a class. A class defines all the attributes which an object can
have and methods which represent the functionality of the object.
3. Messages: Objects communicate by passing messages. Messages consist
of the integrity of the target object, the name of the requested operation,
and any other action needed to perform the function. Messages are often
implemented as procedure or function calls.
 4. Abstraction In object-oriented design, complexity is handled using
abstraction. Abstraction is the removal of the irrelevant and the
amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept.
The data and operations are linked to a single unit. Encapsulation not only
bundles essential information of an object together but also restricts
access to data and methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner
where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate superclasses. This property
of OOD is called an inheritance. This makes it easier to define a specific
class and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned the same
name. This is known as polymorphism, which allows a single interface to
perform functions for different types. Depending upon how the service is
invoked, the respective portion of the code gets executed.

Feature Decision Table Decision Tree

It is a structured way to Visual representation of

Purpose represent conditions decisions and their
and actions. consequences.

Tabular format with Tree-like diagram with

Structure
columns and rows. branches and nodes.

It is useful to handle a It is simpler to understand and

Complexity Management variety of complex analyze within structures of
combinations. hierarchy.

It requires careful setting

Very easy to follow, even for
Ease of Use up of all possible
non-experts.
conditions.
 It facilitates exhaustive It facilitates quick identification
Test Case Design
test case generation. of decision paths.

Lists all possible It divides conditions into

Conditions Handling combinations of branches, each of which is
conditions. evaluated separately.

When there are many When decisions can be easily

Best Use Cases
interrelated conditions. broken down hierarchically.

Definition of Information Hiding principle

Information Hiding hides the design decision of a component that is
likely to change in the future from other components who depends on
it. As such, the programmer only needs to know the input required by
the functions in the component and the expected output that the
functions will produce. This also means that the programmer does not
need to know how the functions are implemented to use them.

How can Information Hiding principle be applied?

To illustrate information hiding, we will use a scenario of a House Buyer

and a Builder. The buyer wants to build a house of its own, so he employs
the construction builder to build it for him. Below is a simplified version
of the scenario mentioned.
 UML Sequence diagram before Information Hiding applied

From the above sequence chart, you can tell that we are exposing too
much information about building a house to the Buyer. The Buyer
must know what functions to call and the sequence of functions to
execute to be able to build a house. However, the Buyer should not
need to know how a house is built. Also, this makes it difficult to
accommodate any changes to the design decision of how a house is being
built because whenever you make a change to the design decision, you
must modify Buyer component as well. As such, information hiding
principle is not utilized.

Applying Information Hiding principle

As mentioned above, the Buyer component should not need to know
how a house is built. As such, we can encapsulate the functions used to
build a house into another component called Builder. Below is the
modified version.

UML Sequence diagram after Information Hiding applied

From the sequence chart above, you can see that information regarding
how a house is built is hidden from the Buyer. The Buyer only needs to
know what materials it needs to pass into the Builder component to get
a house. If the builder is to change the way it builds the house, the
modification will only be done in the Builder component, and it will not
affect the Buyer component. As such, this structure uses the
Information Hiding principle.

Importance of Information Hiding principle

Flexibility
Information Hiding principle provides flexibility to the programmer to
modify underlying design decisions made in a certain component. Since
the implementation details are hidden from the users of the component,
changes made will be localized to that component only. This also makes
debugging and maintaining the program easier.

Information Hiding vs Encapsulation vs Abstraction

These three terms are used commonly when discussing good practices
in software development. Although they are like each other
conceptually, they are not the same. Below is the difference between
these three terms.

Information Hiding principle emphasizes restricting access to

information such as critical design decisions to allow implementations
details to be modified without affecting its users. For example, hiding a
computation algorithm in a component and allowing users to access its
function through an interface.

Encapsulation principle emphasizes controlling access to information

by grouping or wrapping related items together to hide the complexity.
For example, creating a Car component that wraps up all mechanical
parts of a car in a single unit.

Abstraction principle emphasizes hiding unwanted details so that a

programmer can focus on information of greater importance. It is
usually used in high-level components to give an overview of the
component where we abstract the nitty-gritty details about the
implementation away from our core components. For example, in the
main function of a driver class, it calls a ‘run’ function of a component
to get it to work and ‘stop’ function if we want to stop it.

Software Reuse
In most engineering disciplines, systems are designed by composing existing components that have been used
in other systems. Software engineering has been more focused on original development, but it is now recognized
that to achieve better software, more quickly and at lower cost, we need a design process that is based on
systematic software reuse. There has been a major switch to reuse-based development over the past 10 years.

Scale of software reuse:

 System reuse: Complete systems, which may include several application programs.
 Application reuse: An application may be reused either by incorporating it without change into
another or by developing application families.
 Component reuse: Components of an application from sub-systems to single objects may be
reused.
 Object and function reuse: Small-scale software components that implement a single well-
defined object or function may be reused.

Benefits of software reuse:

 Accelerated development: Bringing a system to market as early as possible is often more

important than overall development costs. Reusing software can speed up system production
because both development and validation time may be reduced.
 Effective use of specialists: Instead of doing the same work repeatedly, application specialists
can develop reusable software that encapsulates their knowledge.
 Increased dependability: Reused software, which has been tried and tested in working systems,
should be more dependable than new software. Its design and implementation faults should have
been found and fixed.
 Lower development costs: Development costs are proportional to the size of the software being
developed. Reusing software means that fewer lines of code must be written.
 Reduced process risk: The cost of existing software is already known, whereas the costs of
development are always a matter of judgment. This is an important factor for project management
because it reduces the margin of error in project cost estimation. This is particularly true when
relatively large software components such as subsystems are reused.
 Standards compliance: Some standards, such as user interface standards, can be implemented
as a set of reusable components. For example, if menus in a user interface are implemented using
reusable components, all applications present the same menu formats to users. The use of standard
user interfaces improves dependability because users make fewer mistakes when presented with a
familiar interface.

Problems with software reuse:

 Creating, maintaining, and using a component library: Populating a reusable component

library and ensuring the software developers can use this library can be expensive. Development
processes must be adopted to ensure that the library is used.
  Finding, understanding, and adapting reusable components: Software components must
be discovered in a library, understood and, sometimes, adapted to work in a new environment.
Engineers must be reasonably confident of finding a component in the library before they include
component search as part of their normal development process.
 Increased maintenance costs: If the source code of a reused software system or component is
not available then maintenance costs may be higher because the reused elements of the system
may become increasingly incompatible with system changes.
 Lack of tool support: Some software tools do not support development with reuse. It may be
difficult or impossible to integrate these tools with a library components system. The software
process assumed by these tools may not take reuse into account. This is particularly true for tools
that support embedded systems engineering, less so for object-oriented development tools.
 Not-invented-here syndrome: Some software engineers prefer to rewrite components because
they believe they can improve on them. This is partly to do with trust and partly to do with the fact
that writing original software is seen as more challenging than reusing other people's software.

The reuse landscape

Although reuse is often simply thought of as the reuse of system components, there are many different
approaches to reuse that may be used. Reuse is possible at a range of levels from simple functions to complete
application systems. The reuse landscape covers the range of possible reuse techniques.

Key factors for reuse planning:

 The development schedule for the software.

 The expected software lifetime.
 The background, skills and experience of the development team.
 The criticality of the software and its non-functional requirements.
 The application domain.
 The execution platform for the software.