Cairo University
Faculty of Computing and Artificial Intelligence
SCS253 Software Process & Quality Management
Spring (2025) – Dr. Shaimaa Galal
Lab 4: Clean Coding Techniques for Software Development
Clean Code
What is Clean Code?
Clean code is code that is:
• Easy to read
• Easy to modify
• Easy to test
• Easy to understand
Key Idea
Clean code is written for humans first, not only computers.
Clean Code vs Bad Code
BAD CODE
short names
long functions
duplicate logic
no formatting
mixed responsibilities
CLEAN CODE
meaningful names
small functions
no duplication
consistent format
single responsibility
Characteristics of Clean Code
Readability → easy to read
Maintainability → easy to modify
Testability → easy to test
Efficiency → optimized performance
Collaboration → easy teamwork
Lab 4 1
Clean Code Characteristics
Readability
Readability means the code is easy to read and understand like normal
English.
Why important:
When another developer reads your code, they understand it immediately
without asking you.
Bad
int x = 5;
Problem: variable name unclears.
Good
int numberOfStudents = 5;
Clear meaning
Easy to understand
Maintainability
Maintainability means the code is easy to modify, update, and fix later.
Why important:
Software changes often, so code must be flexible.
Bad
tax = price * 0.14
total = price + price * 0.14
Problem: tax repeated twice (hard to update)
Good
tax = calculateTax(price)
total = price + tax
Change tax in one place only
Easy to maintain
Testability
Testability means the code is easy to test and debug.
Why important:
Small pieces of code are easier to test than large complex functions.
Bad
function doEverything()
Problem: one function doing everything.
Lab 4 2
Good
validateInput()
calculateTotal()
saveOrder()
Each function tested separately
Easy debugging
Efficiency
Efficiency means the code runs fast and uses less memory and resources.
Why important:
Efficient code improves application speed, performance, and responsiveness.
Bad
for(i=0; i<[Link]; i++){
for(j=0; j<[Link]; j++){
// unnecessary repeated loop
}
}
Problem:
• Unnecessary nested loops
• Slower performance
Good
for(i=0; i<[Link]; i++){
// single loop only
}
Faster execution
Less CPU usage
Collaboration
Collaboration means the code is easy for multiple developers to work on
together.
Why important:
Projects are built by teams, not one developer. Clean code helps everyone
understand the system.
Bad
int x;
int y;
int z;
Lab 4 3
Problem:
• Other developers don’t understand variables
• Hard to continue development
Good
int totalStudents;
int totalCourses;
int totalInstructors;
Clear names
Team members understand quickly
SOLID Principles
S Single Responsibility Principle (SRP) – One responsibility
O Open/Closed Principle (OCP) – Extend, don’t modify
L Liskov Substitution Principle (LSP) – Child replaces parent
I Interface Segregation Principle (ISP) – Small interfaces
D Dependency Inversion Principle (DIP) – Depend on abstraction
SRP — Single Responsibility Principle
The SRP states that a class should have only one reason to change.
a class should have only one responsibility or job to do
Why important:
If one class has many jobs, any change may break the system.
Bad Design
StudentManager
├ saveStudent
├ sendEmail
├ printReport
└ calculateGrade
Problem: too many responsibilities.
Clean Design
StudentRepository
EmailService
ReportService
GradeCalculator
Each class has one job
Easier to modify
Lab 4 4
OCP — Open Closed Principle
The OCP states that a class should be open for extension but closed for
modification.
you should be able to add new functionality to a class without modifying its
existing code.
Why important:
Modifying old code may introduce bugs.
Bad
if(paymentType == "cash")
if(paymentType == "card")
if(paymentType == "paypal")
Problem: every new payment → change code.
Good
Payment
├ CashPayment
├ CardPayment
└ PayPalPayment
Add new class only
No modification
LSP — Liskov Substitution Principle
The LSP states that subtypes should be substitutable for their base types.
Child class must behave like parent class.
Why important:
To avoid unexpected errors.
Bad
Bird
└ Penguin (cannot fly)
Problem: penguin breaks fly behavior.
Good
Bird
├ FlyingBird
└ NonFlyingBird
Correct hierarchy
No behavior conflict
Lab 4 5
ISP — Interface Segregation Principle
Create small interfaces instead of one large interface, so that clients only
need to depend on the interfaces that are relevant to them.
Why important:
Classes should not implement methods they don’t use.
Bad
Machine
print()
scan()
fax()
Problem: printer forced to implement fax.
Good
Printer
Scanner
Fax
Flexible design
Less unnecessary code
DIP — Dependency Inversion Principle
Depend on interfaces (abstraction), not concrete classes.
This inversion of control helps to reduce coupling between different
components of a system, making it easier to maintain, test, and extend over
time.
Why important:
Allows switching implementations easily.
Bad
OrderService → MySQLDatabase
Problem: tightly coupled.
Good
OrderService → Database Interface
├ MySQL
Flexible
Easy to change database
Lab 4 6
Meaningful Names Standards
Use names that clearly describe purpose.
Why important:
Improves readability and understanding.
Rules
Use descriptive names – Name variables, functions, and classes clearly.
Be consistent – Follow the same naming standard everywhere.
Use domain-specific vocabulary – Reflect real-world concepts in your code.
Bad Names
a
data
temp
x1
Problem: unclear meaning.
Good Names
totalPrice
studentCount
invoiceDate
courseList
Clear and meaningful
Functions Standards
Rule 1: Small Functions
Each function should perform one task.
Why important:
Small functions easier to test and reuse.
Bad
processOrder()
Inside:
• validate
• calculate
• save
Good
validateOrder()
calculateTotal()
saveOrder()
sendEmail()
Clean separation
Lab 4 7
Rule 2: Few Parameters
Functions should have limited parameters.
Why important:
Too many parameters make code complex.
Bad
createUser(name,age,address,phone,email,status)
Good
createUser(user)
Cleaner design
Formatting Standards
Code should follow consistent layout.
Use consistent indentation – Align code blocks uniformly.
Use whitespace – Separate code logically to improve readability.
Limit line length – Keep lines short for clarity and easy reading.
Why important:
Improves readability.
Bad Formatting
if(x){y();z();}
Good Formatting
if (x) {
y();
z();
}
Avoid Duplicate Code
Do not repeat logic.
Why important:
Duplication makes maintenance harder.
Bad
total = price + price * 0.14
discount = price + price * 0.14
Good
tax = calculateTax(price)
Lab 4 8
Comments — When to Use
Comments explain complex logic.
Rule:
Write clear code first, comment only when needed.
Bad Comment
i++ // increase i by 1
Good Comment
// calculate discount based on loyalty program
Clean Code Structure Diagram
Bad Structure
Controller
├ database
├ logic
├ UI
├ validation
Problem: everything mixed.
Good Structure
Controller
├ Service
├ Repository
├ Validator
├ UI
Separation of concerns
Code Reviews
Code reviews ensure quality, collaboration, and maintainability.
Establish Clear Guidelines – Before starting the code review process, make
sure that you have clear guidelines for what clean code.
Why important:
• Reduces disagreements and makes feedback objective.
Be Constructive – Focus on improving the code, not judging the developer.
Why important:
• Encourages learning, reduces defensiveness, and builds team trust.
Lab 4 9
Encourage Collaboration – Make reviews a discussion, not a checklist.
• Ask the developer to explain their approach.
• Discuss alternatives and trade-offs.
• Encourage knowledge sharing.
Why important:
• Improves code quality, spreads knowledge, and builds team skills.
Clean Code Rules
Use meaningful names
One responsibility
Small functions
Avoid duplication
Use interfaces
Follow SOLID
Write testable code
Use proper formatting
Code Reviews
Lab 4 10