This presentation consists of coding rules and guidelines related to software development process.

1. The Coding Guidelines
by
Vishal Singh
(Vishal11380@yahoo.com)

2. Coding
• Coding is undertaken once the design
phase is complete and the design
documents have been successfully
reviewed. In the coding phase, every module
identified and specified in the design document
is independently coded and unit tested.
• The input to the coding phase is the design
document.
• During the coding phase, different modules
identified in the design document are coded
according to the respective module
specifications.

3. Most software development
organizations formulate their own coding
standards that suit them most and
require their engineers to follow these
standards rigorously due to the following
reasons:
• A coding standard gives a uniform
appearance to the codes written by
different engineers.
• It provides sound understanding of the
code.
• It encourages good programming
practice.

4. 2. Programming practice:
• The primary goal of the coding phase
is to translate the given design into
source code in a given programming
language, so that the code is simple
easy to test and easy to understand
and modify.
• So now we will discuss some concepts
related to coding in a language
independent manner.

5. • 2.1 Top-Down and Bottom –up: All design
contains hierarchies as creating a
hierarchy is a natural way to manage
complexity. Most design methodologies for
software also produce hierarchies. The
question at coding time is; given the hierarchy
of modules produced by design, in what order
the modules be built—starting form the top or
starting from the bottom level?.
• In a Top down implementation, the
implementation starts from the top of the
hierarchy and proceeds to the lower levels.
In a Bottom-up implementation the process is
the reverse.

6. • 2.2 Structured programming: Structured
programming is often regarded as “goto-
less” programming. Although extensive use
of gotos is certainly not desirable, structured
program can be written with the use of gotos.
Here we provide a brief discussion on what the
structured programming is.
• A program has a static structure as well as
dynamic structure. The static structure is the
structure of the text of the program, which is
usually just a linear organization of statements
of the program. The dynamic structure of the
program is the sequence of statements
executed during the execution of the program.
• The goal of structured programming is to
ensure that the static structure and the
dynamic structures are the same.

7. 2.3 Information hiding:
• Information hiding can reduce the
coupling between modules and make
the system more maintainable.
• Information hiding is also an effective
tool for managing the complexity of
developing software.
• Another form of information hiding is to
let a module see only those data items
needed by it.

8. • 2.4 Programming style: The
programming style consists of some
standard and guidelines which we will
discuss in the next section of this
presentation.

9. 2.5 Internal documentation:
• Internal documentation of the program
is done by the use of comments. All
languages provide a means for writing
comments in program. Comments are
textual statements that are meant for
the program reader and are not
executed.

10. Comments for a module are often called
prologue for the module. It is best to
standardize the structure of the prologue of
the module. It is desirable if the prologue
contains the following information:
• Module functionality or what the module is
doing.
• Parameters and their purpose.
• Assumptions about the inputs, if any.
• Global variables accessed or modified in the
module.

11. 3. Coding Standards
• General coding standards pertain to how the
developer writes code, so here we will discuss some
important standard regardless of the programming
language being used.
3.1 Indentation
• Proper and consistent indentation is important in
producing easy to read and maintainable programs.
Indentation should be used to:
• Emphasize the body of a control statement such as a
loop or a select statement
• Emphasize the body of a conditional statement
• Emphasize a new scope block

12. 3.2 Inline Comments
• Inline comments explaining the functioning of
the subroutine or key aspects of the
algorithm shall be frequently used.
3.3 Structured Programming
• Structured (or modular) programming
techniques shall be used. GO TO statements
shall not be used as they lead to “spaghetti”
code, which is hard to read and maintain,
except as outlined in the FORTRAN
Standards and Guidelines.

13. • 3.4 Classes, Subroutines, Functions, and
Methods
• Keep subroutines, functions, and methods
reasonably sized. This depends upon the
language being used. A good rule of thumb
for module length is to constrain each
module to one function or action (i.e. each
module should only do one “thing”).
• The names of the classes, subroutines,
functions, and methods shall have verbs in
them. That is the names shall specify an
action, e.g. “get_name”,
“compute_temperature”.

14. 3.5 Source Files
• The name of the source file or script
shall represent its function. All of the
routines in a file shall have a common
purpose.
3.6 Variable Names
• Variable shall have mnemonic or
meaningful names that convey to a
casual observer, the intent of its use.
Variables shall be initialized prior to its
first use.

15. 3.7 Use of Braces
Bad:
if (j == 0)
printf (“j is zero.n”);
Better:
if (j == 0)
{
printf (“j is zero.n”);
}

16. 3.8 Compiler Warnings
• Compilers often issue two types of
messages: warnings and errors. Compiler
warnings normally do not stop the
compilation process. However, compiler
errors do stop the compilation process,
forcing the developer to fix the problem
and recompile.
• Compiler and linker warnings shall be
treated as errors and fixed. Even though
the program will continue to compile in the
presence of warnings, they often indicate
problems which may affect the behavior,
reliability and portability of the code.

17. 4. Coding Guidelines
• General coding guidelines provide the
programmer with a set of best practices
which can be used to make programs
easier to read and maintain.
• Most of the examples use the C
language syntax but the guidelines can
be applied to all languages.

18. • 4.1 Line Length
• It is considered good practice to keep
the lengths of source code lines at or
below 80 characters. Lines longer
than this may not be displayed
properly on some terminals and tools.
Some printers will truncate lines
longer than 80 columns.

19. 4.2 Spacing
The proper use of spaces within a line of code can
enhance readability.
Example:
Bad:
cost=price+(price*sales_tax);
fprintf(stdout ,“The total cost is %5.2fn”,cost);
Better:
cost = price + ( price * sales_tax );
fprintf (stdout, “The total cost is %5.2fn”, cost) ;

20. 4.3 Wrapping Lines
When an expression will not fit on a single line, break
it according to these following principles:
• Break after a comma
Example:
Bad:
longName1 = longName2 * (longName3 +
LongName4 –
longName5) + 4 * longName6 ;
Better:
longName1 = longName2 * (longName3 +
LongName4 – LongName5)
+ 4 * longName6 ;

21. 4.4 Variable Declarations
Variable declarations that span multiple lines
should always be preceded by a type.
Example:
Acceptable:
int price , score ;
Acceptable:
int price ;
int score ;
Not Acceptable:
int price ,
score ;

22. 4.5 Program Statements
Program statements should be limited to
one per line. Also, nested statements
should be avoided when possible.
Example:
Bad:
number_of_names = names.length ; b =
new JButton [ number_of_names ] ;
Better:
number_of_names = names.length ;
b = new JButton [ number_of_names ] ;

23. 4.6 Use of Parentheses
It is better to use parentheses liberally. Even in
cases where operator precedence
unambiguously dictates the order of
evaluation of an expression, often it is
beneficial from a readability point of view to
include parentheses anyway.
Example:
Acceptable:
total = 3 – 4 * 3 ;
Better:
total = 3 – ( 4 * 3 ) ;
Even better:
total = ( -4 * 3 ) + 3 ;

24. 4.7 Inline Comments
• Inline comments promote program
readability.
4.8 Meaningful Error Messages
• Error handling is an important aspect
of computer programming. This not
only includes adding the necessary
logic to test for and handle errors but
also involves making error messages
meaningful.

25. 4.10 Reasonably Sized Functions and
Methods
Software modules and methods should not
contain an excessively large number of lines
of code. They should be written to perform
one specific task. If they become too long,
then chances are the task being performed
can be broken down into subtasks which
can be handled by new routines or methods.
A reasonable number of lines of code for
routine or a method is 200.

26. 5. Software documentation:
Software documentation or source
code documentation is written text
that accompanies computer software.
It either explains how it operates or
how to use it, or may mean different
things to people in different roles.

27. Involvement of people in software life
Documentation is an important part of software
engineering. Types of documentation include:
• Requirements - Statements that identify
attributes, capabilities, characteristics, or
qualities of a system. This is the foundation for
what shall be or has been implemented.
• Architecture/Design - Overview of software.
Includes relations to an environment and
construction principles to be used in design of
software components.
• Technical - Documentation of code, algorithms,
interfaces, and APIs.
• End User - Manuals for the end-user, system
administrators and support staff.
• Marketing - How to market the product and
analysis of the market demand.

28. 5.1 Requirements documentation
Requirements documentation is the
description of what a particular software
does or shall do.
5.2 Architecture/Design documentation
A good architecture document is short on
details but thick on explanation.
A very important part of the design
document is the Database Design
Document (DDD). It contains
Conceptual, Logical, and Physical
Design Elements.

29. 5.3 Technical documentation
This is what most programmers mean when
using the term software documentation.
When creating software, code alone is
insufficient. There must be some text along
with it to describe various aspects of its
intended operation.
5.4 User documentation
Unlike code documents, user documents are
usually far more diverse with respect to the
source code of the program, and instead
simply describe how it is used.

30. There are three broad ways in which user documentation
can be organized.
• Tutorial: A tutorial approach is considered the most
useful for a new user, in which they are guided
through each step of accomplishing particular tasks.
• Thematic: A thematic approach, where chapters or
sections concentrate on one particular area of
interest, is of more general use to an intermediate
user. Some authors prefer to convey their ideas through
a knowledge based article to facilitating the user needs.
This approach is usually practiced by a dynamic
industry, such as this Information technology, where the
user population is largely correlated with the
troubleshooting demands.
• List or Reference: The final type of organizing
principle is one in which commands or tasks are
simply listed alphabetically or logically grouped,
often via cross-referenced indexes. This latter approach
is of greater use to advanced users who know exactly
what sort of information they are looking for.

31. 5.5 Marketing documentation
For many applications it is necessary to have
some promotional materials to encourage
casual observers to spend more time
learning about the product. This form of
documentation has three purposes:-
• To excite the potential user about the product
and instill in them a desire for becoming
more involved with it.
• To inform them about what exactly the
product does, so that their expectations are
in line with what they will be receiving.
• To explain the position of this product with
respect to other alternatives.

32. 6. Code verification techniques
Verification of the output of the coding phase is
primarily intended for detecting errors introduced
during this phase.
6.1 Code reading
Code reading involves careful reading of the code by
the programmer to detect any discrepancies between
the design specifications and the actual
implementation.
6.2 Static analysis
Analysis of programs by methodically analyzing the
program text is called static analysis. Static analysis
is usually performed mechanically by the aid of
software tools.

33. 6.3 Code inspections or reviews
• The review process was started with
the purpose of detecting defects in the
code.
• Code reviews are designed to detect
defects that originate during the coding
process, although they can also detect
defects in detailed design.

34. The following are some of the items that can be
included in a checklist for code reviews:
• Are the pointers set to NULL, where needed?
• Are all the array indexes within bound?
• Are indexes properly initialized?
• Do data definitions exploit the typing capabilities of the
language?
• Do all pointers point to some object?
• Will a loop always terminate?
• Is the loop termination condition correct?
• Is the number of loop execution “off by one”?
• Where applicable, are the divisors tested for zero?
• Are imported data tested for validity?
• Do actual and formal parameters match?
• Are all variables used?
• Are the label unreferenced?

35. 6.5 Unit testing
• Unit testing is a dynamic method for
verification where the program is
actually compiled and executed. It is
one of the most widely used methods
and the coding phase is sometime
called the “coding and unit testing
phase”. As in other forms of testing unit
testing involves executing the code with
some test cases and then evaluating
the results.