Coding is the process of converting system design into
computer-readable instructions using a programming
language.
It
bridges the gap between design documents and
executable programs.
Objectives of Coding
Translate design into working software.
Ensurecorrectness, efficiency, readability, and
maintainability.
Implement data structures and algorithms defined in design.
Minimize complexity and errors.
Readability: Easy to understand by others.
Simplicity: Avoid unnecessary complexity.
Maintainability: Easy to update and fix.
Efficiency: Optimal use of resources (CPU, memory,
time).
Reliability: Handles errors and unexpected inputs
gracefully.
Good software development organizations want their
programmers to maintain to some well-defined and standard
style of coding called coding standards.
They usually make their own coding standards and
guidelines depending on what suits their organization best
and based on the types of software they develop.
Itis very important for the programmers to maintain the
coding standards otherwise the code will be rejected during
code review.
The following are the purpose of having Coding Standards:
A coding standard gives a uniform appearance to the codes
written by different engineers.
It improves readability, and maintainability of the code and
it reduces complexity also.
It helps in code reuse and helps to detect errors easily.
Itpromotes sound programming practices and increases the
efficiency of the programmers.
Limited use of globals: These rules tell about which types of
data that can be declared global and the data that can't be.
Standard headers for different modules: For better
understanding and maintenance of the code, the header of
different modules should follow some standard format and
information. The header format must contain below things that
is being used in various companies:
•Name of the module
•Date of module creation
•Author of the module
•Modification history
•Synopsis of the module about what the module does
•Different functions supported in the module along with their 5
input output parameters
Naming conventions for local variables, global variables,
constants and functions:
Some of the naming conventions are given below:
Meaningful and understandable variables name helps
anyone to understand the reason of using it.
Local variables should be named using camel case lettering
starting with small letter (e.g. localData) whereas Global
variables names should start with a capital letter
(e.g. GlobalData). Constant names should be formed using
capital letters only (e.g. CONSDATA).
It is better to avoid the use of digits in variable names.
6
The names of the function should be written in camel case
Indentation: Proper indentation is very important to
increase the readability of the code. For making the
code readable, programmers should use White
spaces properly. Some of the spacing conventions
are given below:
There must be a space after giving a comma
between two function arguments.
Each nested block should be properly indented
and spaced.
Proper Indentation should be there at the
beginning and at the end of each block in the
program.
All braces should start from a new line and the
7
code following the end of braces also start from a
new line.
Avoid using a coding style that is too difficult to
understand: Code should be easily understandable. The complex
code makes maintenance and debugging difficult and expensive.
Avoid using an identifier for multiple purposes: Each variable
should be given a descriptive and meaningful name indicating the
reason behind using it. This is not possible if an identifier is used for
multiple purposes and thus it can lead to confusion to the reader.
Moreover, it leads to more difficulty during future enhancements.
Code should be well documented: The code should be properly
commented for understanding easily. Comments regarding the
statements increase the understandability of the code.
Length of functions should not be very large: Lengthy functions
are very difficult to understand. That's why functions should be small
enough to carry out small work and lengthy functions should be broken
into small ones for completing small tasks.
8
Try not to use GOTO statement: GOTO statement makes the
program unstructured, thus it reduces the understandability of the
Code review is a systematic examination of source code
to identify errors, improve quality, and ensure compliance
with standards.
Purpose
Detect defects early (before testing).
Improve maintainability.
Share knowledge across team.
Ensure adherence to design and standards.
9
Formal Review – Structured, with roles (author, reviewer,
moderator).
Informal Review – Peer-to-peer review without formal procedure.
Walkthrough – Developer explains code to peers.
Inspection – Detailed, checklist-driven analysis.
Pair Programming – It is a type of review in which two developers work on
the same computer. One of them writes the code and the other one reviews it in real
time. It is a highly interactive form of code review.
Benefits
Improves code quality.
Reduces debugging and testing effort. 10
Encourages collaboration.
A walkthrough is a peer review technique where the author
presents their code (or design document) to a group to get feedback.
Key Characteristics
Conducted by the author of the code.
The author explains logic, flow, and design decisions step by step.
Other team members act as reviewers and give feedback.
Focus is on clarity, correctness, and improvement, not strict
defect logging.
Usually informal (but can be semi-formal if documented).
11
Benefits
Increases understanding of code across the team.
Helps junior developers learn from senior ones.
Identifies misunderstandings early.
Promotes knowledge sharing.🔄
Walkthrough Process
Preparation – Author prepares the code/document and sends it to peers.
Presentation
– Author explains:Purpose of the codeInputs, outputs, and
assumptionsKey logic and flow
Discussion – Reviewers ask questions, spot issues, suggest improvements.
Feedback Recording – Notes taken, but formal defect log not mandatory.
12
Rework (optional) – Author makes changes based on feedback.
Example
Suppose a developer has written a student grading system module:
def calculate_grade(marks):
if marks >= 90:
return "A"
elif marks >= 75:
return "B"
elif marks >= 60:
return "C"
else:
return "F"
“What about marks above 100?”
“Should we handle negative marks?”
“Do we need grade D?”
Suggestions are noted. The author later modifies the code to add input validation.
👉 This improves the code’s robustness before going into inspection or testing
Example (Walkthrough)
Suppose a developer has written a student grading system module:
def calculate_grade(marks):
if marks >= 90:
return "A"
elif marks >= 75:
return "B"
elif marks >= 60:
return "C"
else:
return "F"
The author presents this function in a meeting.
Peers ask questions like:
“What about marks above 100?”
“Should we handle negative marks?”
“Do we need grade D?”
Suggestions are noted. The author later modifies the code to add input validation.
👉 This improves the code’s robustness before going into inspection or testing
13
The author presents this function in a meeting.
Peers ask questions like:
“What about marks above 100?”
“Should we handle negative marks?”
“Do we need grade D?”
Suggestions are noted. The author later modifies the code to add input validation.
“What about marks above 100?”
“Should we handle negative marks?”
“Do we need grade D?”
Suggestions are noted. The author later modifies the code to add input validation.
👉 This improves the code’s robustness before going into inspection or testing
Example (Walkthrough)
Suppose a developer has written a student grading system module:
def calculate_grade(marks):
if marks >= 90:
return "A"
elif marks >= 75:
return "B"
elif marks >= 60:
return "C"
else:
return "F"
The author presents this function in a meeting.
Peers ask questions like:
“What about marks above 100?”
“Should we handle negative marks?”
“Do we need grade D?”
Suggestions are noted. The author later modifies the code to add input validation.
👉 This improves the code’s robustness before going into inspection or testing
14
Inspection is a formal, systematic, and
structured review process in software engineering,
primarily aimed at detecting defects in software
artifacts (such as source code, design documents,
requirements specifications, or test cases) before they
move to later stages of development.
15
Formal & Structured – Inspection is a systematic
process with defined roles (author, moderator,
reviewers, recorder) and strict guidelines.
Defect-Oriented – The primary aim is to identify
defects (errors, omissions, deviations from
requirements/standards) early in the development
process.
Checklist & Role-Based – Reviewers follow checklists
for logic, coding standards, performance, and
security. Each participant has a clear role to ensure
thorough review.
Documentation & Follow-up – All defects are formally
recorded in a defect log, the author performs rework,
16
and the moderator ensures corrections are
completed.
Planning – Moderator selects the work product,
defines objectives, assigns roles.
Overview Meeting – The author introduces the
product and its objectives.
Preparation – Reviewers individually study the
code/design using checklists.
Inspection Meeting – Team meets to identify and
record defects (not to solve them).Rework –
Author corrects defects.
Follow-up – Moderator ensures corrections are
completed and revalidated. 17
Suppose a banking application module is being
inspected
def withdraw(account_balance, amount):
if amount > account_balance:
return "Insufficient Funds"
return account_balance – amount
During inspection, reviewers use a checklist:
Does it validate negative amounts?
Does it handle zero withdrawal?
Are security and logging requirements met? 18
Are naming conventions followed?
Documentation is written text, diagrams, or notes that describe
the design, functionality, and usage of software.
Types
User Documentation → User manuals, help guides, FAQs.
System Documentation → Design documents, architecture
diagrams, ER diagrams.
Technical Documentation → API references, code comments.
Test Documentation → Test plan, test cases, defect reports.
19
Documentation is written text, diagrams, or notes that describe
the design, functionality, and usage of software.
Types
Acts as a reference for future maintenance.
Helps new team members understand the system.
Supports testers and users.
Reduces dependency on original developers.
20