Fundamentals of Software Engineering

Instructor: Meti Dejene

[email protected]
Haramaya University
Chapter 6 - Coding
 What is Coding?
Coding is the practice of writing a set of instructions using one or more of the many
computer programming languages to develop programs/applications/systems.

 Coding is one of the phases in SDLC.

Coding is undertaken once the design phase is complete and the design documents have
been successfully reviewed.

During the coding phase, different modules identified in the design document are coded
according to their respective module specifications.

The goal of the coding or programming activity is to implement the design in the best
possible manner.
 Coding Standards and Guidelines

It is easy to write code but it is challenging to write good code.

 Writing solid code is a skill that can only be acquired by practice.

For this reason, different coding standards & guidelines are formulated to ease the
coding process for programmers.

Coding standards list 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, the error return
conventions, etc.
 Cont.
It is mandatory for the programmers to follow the coding standards.

Compliance of their code to coding standards is verified during code inspection.

Any code that does not conform to the coding standards is rejected during code

review and returned for rework.

In contrast, coding guidelines provide some general suggestions regarding the coding
style to be followed but leave the actual implementation of these guidelines to the
discretion of the individual developers.
 Cont.
Normally, good software development organizations require their programmers to
follow the coding standard rigorously because of the significant business advantages
it offers.

The main advantages of adhering to a standard style of coding are the following:

A coding standard gives a uniform appearance to the codes written by different

engineers.

It facilitates code readability, understanding and code reuse.

It reduces complexity and increases efficiency of the programmers.

It promotes good programming practices.

 Some Coding Standards, Guidelines and Best Paractices
1. Choice of programming language(s): McConnell provides some advice:

 "Every programming language has strengths and weaknesses. Be aware of the specific
strengths and weaknesses of the language you're using."

2. Naming conventions:

 How to name variables, identifiers, constants, methods, classes, packages, etc.

 Use common naming convention such as Camel case (e.g. firstName ), snake case
(e.g. first_name ), Kebab case (e.g. first-name ), pascal case (e.g. FirstName ).

The naming convention may vary based on the language you are working on and what
you are naming.
 Cont.
For Boolean variables and methods the prefix is should be used to avoid confusion

 e.g., isStatus should be used instead of status

 negative boolean variable names (e.g., isNotCorrect) should be avoided.

 The term compute can be used for methods where something is being computed; the
term find can be used where something is being looked up.
 e.g., computeMean(), findMin()

 Exception classes should be suffixed with Exception (e.g., OutOfBoundException).

 Constant names should be formed using capital letters only (e.g., CONSTDATA).
 Cont.
3. Code Commenting:

 Code should be well-documented and self-explanatory.

 Comments are textual statements that are meant for the program reader to aid the
understanding of code.

In general, comments should explain what the code is doing or why the code is there,
so that the code can become almost standalone for understanding the system.

A good style of code commenting is to write to clarify certain non-obvious aspects of

the working of the code, rather than cluttering the code with trivial comments.
 Cont.
4. Code Layout:

 Layout guidelines focus on how a block of code should be indented, how it should
use blank lines, white spaces, etc., to convey program structure and to make it more
easily readable.

5. 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 reduce code understandability;
thereby making maintenance and debugging difficult and expensive.
 Cont.
6. GOTO statements: GOTO’s should be used sparingly and in a disciplined manner.

Only when the alternative to using GOTO’s is more complex should GOTO’s be used.

 If a GOTO must be used, forward transfers (or a jump to a later statement) is more
acceptable than a backward jump.

7. Nesting:

 If nesting of if-then-else constructs becomes too deep, then the logic become harder
to understand.

It becomes difficult to determine the if statement to which a particular else clause is
associated. Thus, where possible, deep nesting should be avoided.
 Cont.
8. Give Importance to Exceptions and Error Handling:
Most programmers tend to give less attention to the possible exceptional cases and tend
to work with the main flow of events, control, and data.
However, it is the exceptional paths that often cause software systems to fail.
 A program might encounter exceptional conditions in such forms as incorrect input,
the incorrect value of some variable, and overflow.
If such situations do arise, the program should not just “crash” or “core dump”; it should
produce some meaningful message and exit gracefully.
Thus, to make it more reliable, a programmer should consider all possibilities and write
suitable exception handlers to prevent failures or loss when such situations occur.
 Cont.
9. Optimize your software only after it works correctly:
 Even experts find it hard to predict performance bottlenecks.
 So, get it right, then make it fast.
 you can improve with performance small changes to you code.
10. Single Responsibility Principle (SRP):
This principle emphasizes that each module, class, or function should have only one
responsibility or reason to change.
11. Keep functions and methods small:
 Small, focused functions and methods are easier to understand, test, and maintain.
 Code Review

One way to test code quality is through review and inspection.

Code review is an effective static testing strategy for eliminating coding errors and for
producing high quality code.

 Code review mainly targets to detect logical, algorithmic, and programming errors.
 The Review Process
In the review process, reviewers are given the code for a couple of days before the
review meeting.

The members note down their findings of their code review and discuss those in a
review meeting where the coder of the module is present.

The programmer usually receives feedback on programming style, choice of algorithm,

and programming techniques.

The different participants gain by being exposed to another programmer’s errors which
they can then consciously try to avoid.

In addition to the commonly made errors, adherence to coding standards is also

checked during code inspection.
 Cont.
Good software development companies collect statistics regarding different types of
errors that are commonly committed by their engineers and identify the types of errors
most frequently committed.

Such a list of commonly committed errors can be used as a checklist during code
inspection to look out for possible errors.

The following is a checklist of some classical programming errors which can be used
during code inspection:

 Use of uninitialized variables

 Non-terminating loops
 Cont.
 Incompatible assignments

 Array indices out of bounds

 Improper storage allocation and deallocation

 Mismatch between actual and formal parameter in procedure calls

 Use of incorrect logical operators or incorrect precedence among operators

 Comparison of equality of floating point values

 Dangling reference caused when the referenced memory has not been allocated
 Version Control and Managing Evolving Code
During the coding process, the code being written by a programmer (or a pair) evolves
(starting from nothing to eventually having a well-tested module).

 i.e., during this process, the code undergoes changes.

Besides the changes due to the development process, code changes are also needed due
to changes in module specifications and requirements.

As a result, many different versions of each software component are created overtime.

In such a dynamic scenario, managing evolving code is a challenge.

 If we do not keep track of these versions, we are liable to include the wrong versions
of these components in our system.
 Cont.

Version control is such a mechanism provided to keep track of the different

versions of software components.

 Version control, also known as source control, is the practice of tracking and
managing changes to software code.

There are several version control systems (tools) that help software teams manage
changes to source code over time.
 Verification and Validation
Verification and validation processes are concerned with checking that software being
developed meets its specification and delivers the functionality expected by the people
paying for the software.

 These checking processes start as soon as requirements become available and

continue through all stages of the development process.

The aim of verification is

 to check that the software meets its stated functional and non-functional
requirements.
 Cont.
Validation, however, is a more general process.

 The aim of validation is to ensure that the software meets the customer’s expectations.

 It goes beyond simply checking conformance with the specification to demonstrating

that the software does what the customer expects it to do.

 Validation is essential because, requirements specifications do not always reflect the

real wishes or needs of system customers and users.

In summary:

‘Validation: Are we building the right product?’

‘Verification: Are we building the product right?’