The Coding Principles

💡 The Coding Principles — The Secret Sauce Behind Every Great Developer! 🚀

Coding isn’t just about making things work — it’s about making them beautiful, efficient, and maintainable. ✨ Whether you’re a beginner or an experienced developer, understanding the core coding principles is like mastering the grammar of software craftsmanship.

In this blog, we’ll uncover all the major principles — from SOLID to DRY, KISS, and beyond — with examples to help you write clean, scalable, and professional code. 🧠💻

🧱 1. SOLID Principles — The Foundation of Object-Oriented Design

The SOLID principles are a set of five golden rules coined by Robert C. Martin (Uncle Bob). They help developers build software that is easy to maintain, extend, and refactor.

🧩 S — Single Responsibility Principle (SRP)

A class should have one and only one reason to change.

Each class or module should focus on one specific functionality.

Example (Bad ❌):

class Report
  def generate_pdf
    # logic to generate PDF
  end

  def send_email
    # logic to send email
  end
end

Better ✅:

class ReportGenerator
  def generate_pdf
    # logic for PDF generation
  end
end

class EmailSender
  def send_email
    # logic for email
  end
end

👉 Benefit: Easier testing and better code organization.

🔄 O — Open/Closed Principle

Software entities should be open for extension, but closed for modification.

You should be able to add new functionality without changing existing code.

Example ✅ (Using inheritance):

class Payment
  def pay
    raise NotImplementedError
  end
end

class CreditCardPayment < Payment
  def pay
    puts "Paid via Credit Card"
  end
end

class PayPalPayment < Payment
  def pay
    puts "Paid via PayPal"
  end
end

👉 Now, you can add a new payment type without altering existing classes.

🔁 L — Liskov Substitution Principle

Subclasses should be replaceable with their parent classes without breaking the app.

This ensures consistency in behavior when child classes are used in place of their parent.

Example ❌:

class Bird
  def fly
    puts "I can fly"
  end
end

class Penguin < Bird
  def fly
    raise "I can't fly!"
  end
end

Better ✅:

class Bird; end

class FlyingBird < Bird
  def fly
    puts "I can fly"
  end
end

class Penguin < Bird
  def swim
    puts "I can swim"
  end
end

🧠 I — Interface Segregation Principle

No client should be forced to depend on methods it does not use.

Break big interfaces into smaller, more specific ones.

Example ✅:

module Printer
  def print; end
end

module Scanner
  def scan; end
end

class MultiFunctionPrinter
  include Printer
  include Scanner
end

class SimplePrinter
  include Printer
end

🔗 D — Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Example ✅:

class Notification
  def initialize(messenger)
    @messenger = messenger
  end

  def send_message
    @messenger.send
  end
end

class EmailMessenger
  def send
    puts "Sending Email..."
  end
end

notification = Notification.new(EmailMessenger.new)
notification.send_message

🧼 2. DRY — Don’t Repeat Yourself

Avoid duplication of logic. Repetition leads to inconsistency.

Example ❌:

def calculate_area_of_square(side)
  side * side
end

def calculate_area_of_rectangle(length, width)
  length * width
end

Better ✅:

def calculate_area(shape)
  shape.area
end

👉 One method can now handle multiple shapes through polymorphism!

💡 3. KISS — Keep It Simple, Stupid

Complexity is the enemy of execution. Write code that is simple, readable, and direct.

Example ❌:

def check_even(num)
  if num % 2 == 0
    return true
  else
    return false
  end
end

Better ✅:

def check_even(num)
  num.even?
end

🪄 4. YAGNI — You Aren’t Gonna Need It

Don’t add functionality until it’s necessary.

Adding extra features “just in case” leads to wasted effort and complexity.

Example ❌:

class Order
  def apply_discount
    # not used yet, maybe in future?
  end
end

Better ✅: Only implement when there’s a real requirement.

🧰 5. Separation of Concerns

Divide your program into distinct sections, each handling a specific concern.

In Rails, this is a core principle:

• Models → Handle data
• Views → Handle presentation
• Controllers → Handle logic

Example ✅:

# Controller
class UsersController
  def show
    @user = User.find(params[:id])
  end
end

🧩 6. Composition Over Inheritance

Prefer using composition (mixing smaller classes/modules) rather than deep inheritance chains.

Example ✅:

module Flyable
  def fly
    puts "Flying high"
  end
end

class Bird
  include Flyable
end

👉 Flexible, reusable, and avoids “diamond inheritance” problems.

🧭 7. Law of Demeter (LoD) — Talk to Friends, Not Strangers

A method should only call methods of:

• Itself
• Its parameters
• Its own fields

Example ❌:

customer.order.payment.process

Better ✅:

customer.process_payment

Encapsulate internal details — keep code loosely coupled!

⚙️ 8. Clean Code Practices

• Use meaningful names (user_count > x1)
• Write small, focused methods
• Avoid long parameter lists
• Comment why, not what
• Refactor regularly 🔁

💬 Final Thoughts

These principles are not rules — they’re guides 🧭 that lead you to elegant, robust, and maintainable software. The more you follow them, the more your code becomes an art rather than a task. 🎨

💬 “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Keep learning, keep refining, and keep coding clean. 🚀💻