Clean Code Principles Cheat Sheet

Naming conventions, function design, and the SOLID principles for writing readable, maintainable code, illustrated with before/after examples.

1 PageBeginnerMar 30, 2026

Naming Conventions

Rules of thumb for choosing clear, honest variable and function names.

Intention-revealing names- elapsedTimeInDays is clearer than d; a name should answer why it exists and what it does
Avoid disinformation- Don't name a variable accountList if it isn't actually a List; don't reuse names with subtly different meanings
Make names searchable- Single-letter names and magic numbers are hard to grep for; prefer MAX_RETRIES over the literal 3
Use pronounceable names- genymdhms is hard to discuss out loud; generationTimestamp is not
Avoid encodings- Modern typed languages and IDEs make Hungarian-notation prefixes like strName or m_ redundant noise
Nouns for classes, verbs for methods- Customer, InvoiceParser vs. calculateTotal(), sendEmail()
One word per concept- Pick fetch, get, or retrieve and use it consistently across the codebase, not all three

Before / After: Naming

The same logic rewritten with intention-revealing names and constants.

python

# Before: unclear names, magic numbers, unclear intentdef calc(x, y):    if x > 18:        return y * 0.1    return 0# After: intention-revealing names and a named constantADULT_AGE = 18SENIOR_DISCOUNT_RATE = 0.1def calculate_senior_discount(age, price):    if age > ADULT_AGE:        return price * SENIOR_DISCOUNT_RATE    return 0

Small, Focused Functions

Splitting a function that does too much into single-purpose steps.

python

# Before: one function doing validation, math, and side effectsdef process_order(order):    if not order.items:        raise ValueError("empty order")    total = sum(i.price * i.qty for i in order.items)    total *= 0.9 if order.customer.is_member else 1.0    send_email(order.customer.email, f"Total: {total}")    save_to_db(order, total)    return total# After: each function operates at one level of abstractiondef process_order(order):    validate_order(order)    total = calculate_total(order)    notify_customer(order.customer, total)    persist_order(order, total)    return total

SOLID Principles

Five object-oriented design principles for maintainable class hierarchies.

S — Single Responsibility- A class or module should have exactly one reason to change
O — Open/Closed- Software entities should be open for extension but closed for modification
L — Liskov Substitution- Subtypes must be substitutable for their base types without breaking correctness
I — Interface Segregation- Clients shouldn't be forced to depend on methods they don't use; prefer several small interfaces
D — Dependency Inversion- Depend on abstractions, not concrete implementations; high-level modules shouldn't depend on low-level details

Pro Tip

A function should do one thing, do it well, and do it only — if you need the word 'and' to describe what a function does, that's a sign it should be split in two.

Was this cheat sheet helpful?

Unit Testing Best Practices Cheat Sheet

Behavioral Design Patterns Cheat Sheet

Explore Topics

#CleanCodePrinciples#CleanCodePrinciplesCheatSheet#Programming#Beginner#NamingConventions#BeforeAfterNaming#SmallFocusedFunctions#SOLIDPrinciples#Functions#CheatSheet#SkillVeris

Sri Hayavadhana Info-Tech

Professional Web Designing Services