DEV Community: Walter Nascimento

Polymorphism: Eliminating Conditionals and Unlocking Extensibility

Walter Nascimento — Sat, 28 Feb 2026 05:59:00 +0000

Most developers think polymorphism means:

“One interface, multiple implementations.”

That’s technically correct.

But architecturally incomplete.

Polymorphism is about this:

Replacing conditional logic with behavioral variation.

If your system grows with switch statements,
you’re not using polymorphism.

You’re fighting it.

A Brief Historical Context

Polymorphism was introduced to allow:

Message passing between objects
Dynamic behavior resolution
Runtime flexibility

Instead of asking:

if ($type === 'credit_card') { ... }

You delegate behavior to the object itself.

That shift changes everything.

❌ The Conditional Explosion Problem

Imagine a pricing system.

final class DiscountCalculator
{
    public function calculate(string $type, float $amount): float
    {
        switch ($type) {
            case 'percentage':
                return $amount * 0.9;

            case 'fixed':
                return $amount - 20;

            case 'none':
                return $amount;

            default:
                throw new InvalidArgumentException('Invalid discount type');
        }
    }
}

Problems:

Violates Open/Closed Principle
Every new discount modifies the class
High risk of regression
Business rules centralized in conditionals
Hard to test behaviors independently

This grows over time.

Switch becomes monster.

✅ Introducing Polymorphism

Define a contract.

interface DiscountStrategy
{
    public function apply(float $amount): float;
}

Implement behaviors separately.

final class PercentageDiscount implements DiscountStrategy
{
    public function __construct(
        private float $percentage
    ) {}

    public function apply(float $amount): float
    {
        return $amount * (1 - $this->percentage);
    }
}

final class FixedDiscount implements DiscountStrategy
{
    public function __construct(
        private float $amountToSubtract
    ) {}

    public function apply(float $amount): float
    {
        return $amount - $this->amountToSubtract;
    }
}

final class NoDiscount implements DiscountStrategy
{
    public function apply(float $amount): float
    {
        return $amount;
    }
}

Now the calculator becomes:

final class PriceCalculator
{
    public function __construct(
        private DiscountStrategy $discountStrategy
    ) {}

    public function calculate(float $amount): float
    {
        return $this->discountStrategy->apply($amount);
    }
}

No conditionals.

Behavior varies by object.

That’s polymorphism.

Why This Is Architecturally Superior

Adding a new discount:

final class SeasonalDiscount implements DiscountStrategy
{
    public function apply(float $amount): float
    {
        return $amount * 0.8;
    }
}

You don’t modify existing code.

You extend behavior safely.

That’s Open/Closed Principle in action.

Polymorphism enables it.

Runtime Polymorphism vs Structural Polymorphism

PHP supports runtime polymorphism through:

Interfaces
Abstract classes
Method overriding

Example:

function checkout(DiscountStrategy $discount, float $amount): float
{
    return $discount->apply($amount);
}

Any implementation works.

Behavior is resolved at runtime.

No conditionals needed.

The Real Power: Removing Knowledge of Types

Conditional logic requires type awareness:

if ($payment instanceof StripePayment) { ... }

Polymorphism removes that knowledge.

The system does not care about concrete type.

It only cares about behavior.

That reduces coupling dramatically.

Advanced Insight: Polymorphism and Domain Modeling

In rich domain models, polymorphism represents real-world behavior variation.

Example:

Instead of:

if ($userType === 'admin') { ... }

Model roles:

interface UserRole
{
    public function canApprove(): bool;
}

final class AdminRole implements UserRole
{
    public function canApprove(): bool
    {
        return true;
    }
}

final class CustomerRole implements UserRole
{
    public function canApprove(): bool
    {
        return false;
    }
}

Now:

final class User
{
    public function __construct(
        private UserRole $role
    ) {}

    public function canApprove(): bool
    {
        return $this->role->canApprove();
    }
}

No role conditionals across the system.

Behavior lives where it belongs.

When Polymorphism Is Overused

Polymorphism becomes harmful when:

You create abstractions without variability
There is only ever one implementation
You abstract prematurely
You hide simple logic behind unnecessary indirection

Like abstraction, polymorphism should follow variation.

Not fear of change.

Polymorphism vs Inheritance

Inheritance enables polymorphism.

But inheritance is not required for polymorphism.

Interfaces + composition are often cleaner.

Modern systems favor:

Composition
Strategy pattern
Interface-driven design

Deep inheritance hierarchies are rarely necessary.

The Architectural Impact

Without polymorphism:

Conditionals multiply
Code becomes rigid
Modifications become risky
Extension requires modification

With polymorphism:

Behavior becomes pluggable
Extension becomes safe
Testing becomes simpler
Systems evolve without breaking

Final Insight

Polymorphism is not about multiple implementations.

It is about removing decision logic from central coordinators.

If encapsulation protects invariants,
if abstraction protects dependency direction,
if inheritance models specialization,

Polymorphism unlocks extensibility.

And extensibility is what keeps systems alive over time.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Inheritance: The Most Misused Pillar of OOP

Walter Nascimento — Fri, 27 Feb 2026 05:59:00 +0000

Inheritance was introduced to promote reuse.

But in modern systems,
it is one of the biggest sources of fragility.

Used correctly, it models specialization.

Used incorrectly, it creates tight coupling, broken abstractions, and subtle bugs.

Inheritance is powerful.

And dangerous.

A Brief Historical Context

Inheritance emerged strongly in Smalltalk and later C++ as a way to:

Reuse behavior
Model taxonomies
Represent “is-a” relationships

But as systems scaled, developers discovered something:

Inheritance couples classes more tightly than composition.

The child class is structurally bound to the parent.

If the parent changes, everything below it may break.

What Inheritance Really Means

Inheritance is:

A specialization relationship
A behavioral extension mechanism
A polymorphic substitution mechanism

Inheritance is not:

A code reuse shortcut
A way to share utilities
A dumping ground for common methods

If your only goal is reuse,
inheritance is often the wrong tool.

❌ The Wrong Way: Inheritance for Reuse

class FileLogger
{
    protected function format(string $message): string
    {
        return date('Y-m-d') . ' - ' . $message;
    }
}

Now someone wants email logging:

class EmailLogger extends FileLogger
{
    public function send(string $message): void
    {
        $formatted = $this->format($message);
        // send email
    }
}

Why is this problematic?

EmailLogger depends on FileLogger
FileLogger was never meant to be a base abstraction
Shared logic forces structural coupling
Changing FileLogger impacts EmailLogger

This is inheritance for reuse.

And it's fragile.

The Rectangle / Square Problem

A classic example.

class Rectangle
{
    protected int $width;
    protected int $height;

    public function setWidth(int $width): void
    {
        $this->width = $width;
    }

    public function setHeight(int $height): void
    {
        $this->height = $height;
    }

    public function area(): int
    {
        return $this->width * $this->height;
    }
}

Now:

class Square extends Rectangle
{
    public function setWidth(int $width): void
    {
        $this->width = $width;
        $this->height = $width;
    }

    public function setHeight(int $height): void
    {
        $this->width = $height;
        $this->height = $height;
    }
}

Seems logical.

But watch this:

function resize(Rectangle $rectangle): int
{
    $rectangle->setWidth(5);
    $rectangle->setHeight(10);

    return $rectangle->area();
}

Expected result: 50.

If we pass Square?

Result: 100.

This violates the Liskov Substitution Principle.

The child cannot safely substitute the parent.

Inheritance broke behavioral expectations.

The Real Rule of Inheritance

For inheritance to be valid:

The child must fully respect the behavioral contract of the parent.

Not just the method signatures.

The behavior.

If overriding changes expectations,
inheritance is wrong.

When Inheritance Is Appropriate

Inheritance works well for:

Framework base classes (with strict contracts)
Template Method pattern
Controlled extensibility
Internal engine hierarchies

Example:

abstract class ReportGenerator
{
    public function generate(): void
    {
        $data = $this->collectData();
        $this->export($data);
    }

    abstract protected function collectData(): array;
    abstract protected function export(array $data): void;
}

Concrete implementations specialize behavior without breaking the algorithm structure.

That’s safe inheritance.

Prefer Composition Over Inheritance

Instead of:

class EmailLogger extends FileLogger

Use composition:

final class LoggerFormatter
{
    public function format(string $message): string
    {
        return date('Y-m-d') . ' - ' . $message;
    }
}

final class EmailLogger
{
    public function __construct(
        private LoggerFormatter $formatter
    ) {}

    public function send(string $message): void
    {
        $formatted = $this->formatter->format($message);
        // send email
    }
}

Now:

✔ No structural coupling
✔ Reuse without hierarchy
✔ Replaceable components
✔ Safer evolution

Composition isolates change.

Inheritance propagates change.

The Fragility Problem

Inheritance creates:

Tight coupling
Implicit dependencies
Hidden assumptions
Deep hierarchy complexity
Hard-to-reason systems

The deeper the hierarchy,
the harder the system becomes to maintain.

Modern architectures prefer shallow hierarchies and composition.

Advanced Insight: Inheritance and Encapsulation Conflict

Inheritance can weaken encapsulation.

Protected properties allow subclasses to manipulate internal state.

That breaks invariants.

That weakens object boundaries.

That introduces subtle bugs.

This is why many modern systems favor:

Final classes
Composition
Interfaces over abstract base classes

When NOT to Use Inheritance

Avoid inheritance when:

You only want code reuse
You cannot guarantee behavioral substitution
The base class wasn’t designed for extension
You foresee independent evolution

Final Insight

Inheritance is about specialization, not reuse.

If encapsulation protects internal state
and abstraction protects dependency boundaries

Inheritance must protect behavioral contracts.

Used correctly, it models true “is-a” relationships.

Used carelessly, it introduces silent architectural decay.

Inheritance is powerful.

That’s why it must be used carefully.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Abstraction: Designing Systems That Don’t Collapse Under Complexity

Walter Nascimento — Thu, 26 Feb 2026 05:59:00 +0000

Encapsulation protects invariants.

Abstraction protects architecture.

If encapsulation controls state,
abstraction controls dependency.

And without it, your system slowly turns into a fragile web of concrete implementations.

A Brief Historical Context

Abstraction became critical when software systems stopped being small.

In early OOP systems, objects communicated directly with concrete implementations.

But as systems grew:

Infrastructure changed
Databases evolved
APIs were replaced
Vendors switched

Hard-coded dependencies became the biggest source of rigidity.

Abstraction emerged as a way to:

Depend on behavior contracts, not implementations.

That single idea made large systems survivable.

What Abstraction Really Means

Abstraction is:

Defining behavior without exposing implementation
Programming against contracts
Isolating high-level logic from low-level details
Reducing coupling

Abstraction is not:

Just creating interfaces everywhere
Adding layers for no reason
Over-engineering small systems

Abstraction is about managing volatility.

❌ The Problem: Concrete Coupling

Let’s say we’re building a payment service.

final class OrderService
{
    public function pay(float $amount): void
    {
        $stripe = new StripePaymentGateway();
        $stripe->charge($amount);
    }
}

What’s wrong?

OrderService depends directly on Stripe
Impossible to switch provider without editing business logic
Hard to test
Violates dependency inversion
Infrastructure leaks into domain logic

This is tight coupling.

Why This Becomes Dangerous

Imagine:

Stripe increases fees
You must support PayPal
A region requires a local provider
Stripe API changes

Now you must modify core logic.

Your domain is polluted by infrastructure decisions.

That’s architectural fragility.

✅ Introducing Abstraction

We define a contract.

interface PaymentGateway
{
    public function charge(float $amount): void;
}

Now we create implementations.

final class StripePaymentGateway implements PaymentGateway
{
    public function charge(float $amount): void
    {
        // Call Stripe API
    }
}

final class PaypalPaymentGateway implements PaymentGateway
{
    public function charge(float $amount): void
    {
        // Call PayPal API
    }
}

Now we depend on abstraction.

Refactoring the Service

final class OrderService
{
    public function __construct(
        private PaymentGateway $paymentGateway
    ) {}

    public function pay(float $amount): void
    {
        $this->paymentGateway->charge($amount);
    }
}

Now:

✔ OrderService does not know about Stripe
✔ Infrastructure can change
✔ Testing becomes trivial
✔ Domain logic is protected

This is abstraction.

Abstraction and Dependency Direction

The critical rule:

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

This is the foundation of the Dependency Inversion Principle.

Your domain should never depend on Stripe.

Stripe should depend on your abstraction.

Architectural Impact

With abstraction:

You can switch providers
You can mock dependencies
You isolate external volatility
You maintain stable core logic

Without abstraction:

Refactoring becomes dangerous
Tests require real infrastructure
Every change ripples across the system

Advanced Insight: Abstraction is About Volatility Isolation

Ask yourself:

What changes frequently?

External APIs
Databases
Message brokers
File storage
Email providers

These are volatile dependencies.

Your core business rules are stable.

Abstraction isolates stable from unstable.

When Abstraction Is Overkill

Abstraction adds indirection.

Do not abstract:

Simple scripts
Tiny applications
One-off utilities
Stable internal code with no variability

Premature abstraction creates:

Interface pollution
Unnecessary complexity
Cognitive overhead

Abstraction should follow variability, not fear.

Abstraction vs Encapsulation

Encapsulation protects internal state.

Abstraction protects dependency boundaries.

Encapsulation works inside the object.

Abstraction works between objects.

Together, they define structural integrity.

Common Anti-Patterns

1️⃣ Interface Per Class

interface UserServiceInterface {}
class UserService implements UserServiceInterface {}

No variability.

No alternative implementation.

Just noise.

2️⃣ Leaky Abstractions

interface PaymentGateway
{
    public function chargeWithStripeToken(string $token): void;
}

Stripe-specific logic inside abstraction.

That defeats the purpose.

Final Insight

Abstraction is not about hiding code.

It is about controlling dependency direction.

If encapsulation prevents internal chaos,
abstraction prevents architectural collapse.

Abstraction allows your system to evolve without rewriting its core.

That is why it is the second pillar of OOP.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Encapsulation: The Pillar That Protects Your Domain from Chaos

Walter Nascimento — Wed, 25 Feb 2026 19:22:57 +0000

Before SOLID.
Before Clean Architecture.
Before Design Patterns.

There was one fundamental idea:

Objects must protect their own state.

Encapsulation is not about hiding properties.

It is about preserving invariants and controlling state transitions.

If your object can enter an invalid state,
you don’t have encapsulation.

You have a mutable data structure with methods attached.

A Brief Historical Context

Encapsulation was formalized in the 1970s with Simula and later reinforced by Smalltalk.

The motivation was simple:

Procedural systems relied heavily on shared mutable state.
That led to:

Hidden side effects
Fragile code
Tight coupling
Hard-to-reason systems

Object-Oriented Programming proposed a radical constraint:

Data should only be modified through behavior defined by the object itself.

Encapsulation was born as a protection mechanism.

What Encapsulation Actually Means

Encapsulation is:

Restricting direct access to internal state
Exposing behavior instead of raw data
Enforcing invariants at construction and mutation
Preventing invalid state transitions

Encapsulation is not:

Just using private
Generating getters and setters for everything
Hiding data without protecting it

Encapsulation is about control.

❌ The Illusion of Encapsulation

Let’s look at a common example.

class BankAccount
{
    public float $balance = 0.0;

    public function deposit(float $amount): void
    {
        $this->balance += $amount;
    }

    public function withdraw(float $amount): void
    {
        $this->balance -= $amount;
    }
}

What’s wrong?

Public mutable state
No invariant protection
Negative balances allowed
Invalid transitions possible

This is not an object.

It’s a struct with methods.

The Real Problem: Broken Invariants

An invariant is a condition that must always be true.

For a bank account:

Balance cannot be negative
Deposit must be positive
Withdraw cannot exceed balance

With the previous implementation:

$account = new BankAccount();
$account->balance = -1_000_000;

Your domain is corrupted.

Encapsulation failed.

✅ Proper Encapsulation in PHP

final class BankAccount
{
    private float $balance;

    public function __construct(float $initialBalance)
    {
        if ($initialBalance < 0) {
            throw new InvalidArgumentException(
                'Initial balance cannot be negative.'
            );
        }

        $this->balance = $initialBalance;
    }

    public function deposit(float $amount): void
    {
        if ($amount <= 0) {
            throw new InvalidArgumentException(
                'Deposit amount must be positive.'
            );
        }

        $this->balance += $amount;
    }

    public function withdraw(float $amount): void
    {
        if ($amount <= 0) {
            throw new InvalidArgumentException(
                'Withdraw amount must be positive.'
            );
        }

        if ($amount > $this->balance) {
            throw new RuntimeException(
                'Insufficient funds.'
            );
        }

        $this->balance -= $amount;
    }

    public function balance(): float
    {
        return $this->balance;
    }
}

Notice the structural improvements:

private state
Guard clauses
Controlled transitions
final class (prevent unsafe inheritance)

Now the object:

✔ Cannot be constructed invalid
✔ Cannot transition to invalid state
✔ Protects its invariants
✔ Exposes behavior, not data

This is encapsulation.

Encapsulation and State Transitions

Encapsulation is fundamentally about controlling transitions.

Instead of:

$account->balance = 500;

We model domain behavior:

$account->deposit(500);

Why does this matter?

Because behavior is extensible.

Inside deposit() we could later:

Dispatch domain events
Log transactions
Validate limits
Apply fees
Trigger auditing
Wrap in transaction boundaries

Encapsulation enables architectural evolution.

Direct state mutation blocks it.

The Getter/Setter Trap

Many developers think this is encapsulation:

private float $balance;

public function getBalance(): float
{
    return $this->balance;
}

public function setBalance(float $balance): void
{
    $this->balance = $balance;
}

This is not encapsulation.

This is a public property with ceremony.

The invariant is still unprotected.

If you can arbitrarily set state,
your object is still fragile.

Encapsulation in Domain-Driven Design

In DDD, an Aggregate Root must:

Protect its invariants
Control all state changes
Prevent invalid operations

Example of what not to do:

public function setStatus(string $status): void
{
    $this->status = $status;
}

Better:

public function approve(): void
{
    if ($this->status !== 'pending') {
        throw new DomainException('Only pending orders can be approved.');
    }

    $this->status = 'approved';
}

Behavior-driven transitions preserve consistency.

Encapsulation is what makes aggregates reliable.

Advanced Technique: Immutability with readonly

PHP 8.1 introduced readonly.

For value objects:

final class Money
{
    public function __construct(
        public readonly int $amount,
        public readonly string $currency
    ) {
        if ($amount < 0) {
            throw new InvalidArgumentException('Amount cannot be negative.');
        }
    }
}

Immutable objects are the strongest form of encapsulation.

They:

Prevent mutation entirely
Eliminate side effects
Improve reasoning
Reduce concurrency issues

Encapsulation + Immutability = Stability.

Common Anti-Patterns

1️⃣ Anemic Domain Model

class User
{
    public string $email;
    public string $password;
}

All business logic lives in services.

This is procedural code disguised as OOP.

2️⃣ Returning Internal Collections

public function items(): array
{
    return $this->items;
}

External code can mutate internal state.

Better:

Return copies
Return iterators
Provide addItem() / removeItem() methods

The Architectural Impact

Without encapsulation:

Inheritance becomes dangerous
Polymorphism becomes unpredictable
Abstractions leak
Concurrency issues increase
Testing becomes harder

Encapsulation is not a syntax feature.

It is an architectural constraint.

Final Insight

The goal of encapsulation is simple:

Make invalid states unrepresentable.

If your object depends on external discipline to remain valid,
it is not encapsulated.

Encapsulation is the first pillar for a reason.

It protects your domain from chaos.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Binary: The Language Your Computer Actually Speaks

Walter Nascimento — Mon, 23 Feb 2026 19:57:39 +0000

Everything in software engineering eventually collapses into something extremely simple:

0 and 1

Not strings.
Not objects.
Not JSON.
Not even machine instructions in the way we imagine them.

Just electrical states.

If you truly want to understand how computers work, you need to understand binary and how it eventually becomes text through something like ASCII.

Let’s break it down from the absolute beginning.

What Is Binary?

Binary is a base-2 number system.

While humans use base-10 (0–9), computers use:

0
1

Why?

Because hardware operates on physical states:

Off / On
Low voltage / High voltage
False / True

Transistors, the building blocks of CPUs can only represent two stable states. That maps perfectly to binary digits.

That’s why computers don’t "prefer" binary.

They are physically built around it.

What Is a Bit?

A bit (binary digit) is the smallest unit of information.

It can only be:

0
or
1

Alone, a bit isn’t very useful.

But when you combine them, something powerful happens.

What Is a Byte?

A byte is a group of 8 bits.

Example:

00000000

With 8 bits, we can represent:

2^8 = 256 possible values

That means:

0 to 255

This is the first important turning point.

Because now we can represent numbers.

And once we can represent numbers, we can represent anything.

How Binary Represents Numbers

Binary works exactly like decimal except each position represents a power of 2 instead of 10.

Example:

1010₂

Each position means:

1×2³ + 0×2² + 1×2¹ + 0×2⁰

Which equals:

8 + 0 + 2 + 0 = 10

So:

1010₂ = 10₁₀

It’s not magic.

It’s just positional notation.

So How Do Numbers Become Letters?

Here’s where things get interesting.

Computers don’t understand letters.

They understand numbers.

So we need a mapping:

Number → Character

That mapping is called ASCII.

What Is ASCII?

ASCII stands for:

American Standard Code for Information Interchange

It’s simply a table that assigns numbers to characters.

For example:

Decimal	Binary	Character
65	01000001	A
66	01000010	B
97	01100001	a

So when you type:

The computer stores:

Which in binary is:

01000001

That’s it.

There is no “A” inside the computer.

Only numbers.
Only bits.

Let’s Decode a Real Example

Take this binary sequence:

01001000 01101001

Break it into bytes:

01001000 = 72
01101001 = 105

Now check ASCII:

72  → H
105 → i

The result?

Hi

That’s how text exists inside memory.

The Full Journey: From Electricity to Text

Let’s connect everything:

Electricity changes state (on/off).
That becomes 0 or 1.
Bits form bytes (8 bits).
Bytes represent numbers (0–255).
Numbers map to characters using ASCII.
The operating system renders the character on your screen.

Every string in your code follows this pipeline.

Every log.
Every API response.
Every database record.

Still just bits.

But ASCII Isn’t Enough

The original ASCII uses 7 bits (128 characters).

That works for:

Basic English letters
Numbers
Symbols

But it doesn’t support:

Accents (é, ç, ñ)
Asian languages
Emojis

That’s why modern systems use:

Unicode
UTF-8

But even UTF-8?

Still binary underneath.

Always binary.

Why This Matters for Engineers

Understanding binary is not about memorizing conversions.

It’s about understanding abstraction layers.

When something breaks due to:

Encoding issues
Corrupted data
Serialization bugs
“Invalid byte sequence” errors

You are no longer debugging strings.

You are debugging binary representations.

The engineer who understands the foundation solves problems faster.

The one who ignores it stays confused at the surface.

Final Thought

Computers don’t understand:

Code
APIs
JSON
Databases
Frameworks

They understand:

0 and 1

Everything else is abstraction.

And the better you understand the bottom layer,
the stronger your engineering intuition becomes.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

YAGNI: The Principle That Protects You From Building the Future Too Early

Walter Nascimento — Thu, 12 Feb 2026 18:42:30 +0000

Most developers don’t struggle with laziness.

They struggle with imagination.

We imagine scale.
We imagine new features.
We imagine flexibility.
We imagine “what if”.

And that’s exactly where YAGNI comes in.

What YAGNI Really Means

YAGNI stands for:

You Aren’t Gonna Need It

The rule is brutally simple:

If you don’t need it now, don’t build it now.

Not “just in case”.
Not because it looks architecturally elegant.

Where YAGNI Came From

YAGNI was introduced as part of Extreme Programming (XP) in the late 1990s by Kent Beck.

Extreme Programming challenged traditional software thinking:

Deliver fast
Iterate often
Refactor constantly
Avoid speculative design

Instead of predicting every future scenario, XP embraced incremental evolution.

YAGNI became one of its core disciplines.

Not because future-proofing is bad.

But because speculative complexity is expensive.

The Real Enemy: Speculative Engineering

Most violations of YAGNI look intelligent.

They look like:

Adding abstraction layers “for scalability”
Creating interfaces for implementations that don’t exist
Building configuration systems before variation is real
Designing for multi-tenancy with a single client

The reasoning is always the same:

“We might need this.”

But most of the time?

You won’t.

And you just increased:

Cognitive load
Maintenance cost
Bug surface area
Onboarding friction

All for a future that never arrived.

A Simple Example

Let’s say you only use Stripe.

❌ Overengineered version

class PaymentStrategy:
    def execute(self, amount):
        pass


class StripeStrategy(PaymentStrategy):
    def execute(self, amount):
        return f"Processing {amount} with Stripe"


class PayPalStrategy(PaymentStrategy):
    def execute(self, amount):
        return f"Processing {amount} with PayPal"


class PaymentProcessor:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy

    def process(self, amount):
        return self.strategy.execute(amount)

Looks clean.
Looks extensible.
Looks “architectural”.

But there is no PayPal.
There is no roadmap.
There is no second gateway.

You built optionality that does not exist.

✅ YAGNI version

class PaymentProcessor:
    def process(self, amount):
        return f"Processing {amount} with Stripe"

Simple.
Clear.
Honest.

If PayPal becomes real?

You refactor.

And refactoring is cheaper than maintaining imaginary flexibility.

“But What About Scaling?”

This is where people panic.

They think YAGNI means:

Ignore design
Ignore growth
Ignore architecture

It doesn’t.

YAGNI doesn’t reject foresight.
It rejects speculation without evidence.

There’s a famous quote by Donald Knuth:

“Premature optimization is the root of all evil.”

YAGNI applies the same logic to architecture.

Premature abstraction is just optimization’s cousin.

YAGNI Is About Timing

Engineering is not about building everything correctly on day one.

It’s about:

Building what’s necessary
Validating assumptions
Refactoring when reality demands change

Not when imagination suggests it might.

The best engineers don’t design for every possible future.

They design for change.

That’s different.

When YAGNI Does NOT Apply

YAGNI is powerful.
But not absolute.

You should not apply YAGNI when:

Requirements are contractual and confirmed
Multiple implementations are guaranteed
Public APIs must remain stable
The cost of change later is extremely high

YAGNI fights uncertainty-driven complexity.

It does not fight clarity-driven design.

The Psychological Side of YAGNI

YAGNI is hard because it challenges ego.

Developers often want to:

Prove architectural depth
Demonstrate pattern knowledge
Show foresight
Avoid looking “unprepared”

But mature engineering is not about showing how much you know.

It’s about delivering the simplest correct solution.

Restraint is a skill.

And YAGNI is discipline in action.

The Question That Changes Everything

Before adding:

A new abstraction
A new pattern
A new configuration layer
A new generic system

Ask yourself:

Is this solving a real, current problem?

If not…

You probably aren’t gonna need it.

Final Thought

Software evolves.

Your system will change.
Requirements will shift.
Users will surprise you.

Trying to predict everything is not wisdom.

It’s fear disguised as architecture.

YAGNI reminds us:

Build for now.
Refactor when needed.
Trust evolution.
Respect simplicity.

And most importantly:

Don’t sacrifice today’s clarity for tomorrow’s imagination.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

DRY: The Principle That Most Developers Misunderstand

Walter Nascimento — Wed, 11 Feb 2026 20:15:55 +0000

Most developers think DRY (Don’t Repeat Yourself) is about avoiding duplicate code.

It’s not.

At least, not primarily.

DRY is about protecting knowledge integrity inside a system.

And the difference between those two interpretations is what separates someone who “removes duplication” from someone who designs resilient systems.

Let’s unpack this properly.

Where DRY Actually Came From

The DRY principle was formally introduced in 1999 in the book The Pragmatic Programmer by Andrew Hunt and David Thomas.

But it didn’t emerge as a stylistic suggestion.

It emerged as a response to a painful, recurring problem in software engineering:

Systems were breaking because knowledge was scattered.

The original formulation was:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Notice something important.

It says knowledge, not “lines of code.”

At the end of the 90s, software systems were growing rapidly:

Large monoliths
Increasing web adoption
Enterprise systems scaling fast
Low discipline around refactoring

When business rules were duplicated across modules, updating them required changing multiple places. Inevitably, someone forgot one.

The result?

Inconsistent behavior.
Hidden bugs.
Loss of trust.

DRY was not about elegance.

It was about survival.

The Real Meaning of DRY

If you reduce DRY to “don’t copy-paste code,” you are already misunderstanding it.

DRY is about ensuring that a single business rule, assumption, or decision lives in one authoritative place.

For example:

Bad (violates DRY at the knowledge level):

def calculate_vat(price):
    return price * 0.23

def calculate_invoice_total(price):
    vat = price * 0.23
    return price + vat

If VAT changes to 21%, you must remember to update two places.

That’s duplicated knowledge.

Better:

VAT_RATE = 0.23

def calculate_vat(price):
    return price * VAT_RATE

def calculate_invoice_total(price):
    vat = calculate_vat(price)
    return price + vat

Now the tax rule has a single authoritative representation.

That’s DRY.

But here’s where it gets interesting.

DRY Is Not About Removing All Repetition

Many developers take DRY too far.

They see similar-looking code and immediately try to abstract it.

Two functions look 70% similar?
“Let’s create a generic helper!”

Three classes share some logic?
“Let’s create a base class!”

This is where DRY becomes dangerous.

Because similarity is not identity.

Two pieces of code can look similar but represent different knowledge.

And if they evolve differently later, your shared abstraction becomes a liability.

Experienced engineers ask:

Will these behaviors change together?

If the answer is uncertain, duplication might be safer than premature abstraction.

DRY in Modern Architectures

In monoliths, DRY is relatively straightforward.

In distributed systems, it becomes more nuanced.

Imagine two microservices:

User Service
Billing Service

Both define a User model.

Is that duplication?

Technically yes.

Architecturally? Not necessarily.

If both services depend on a shared library for User, you create:

Versioning complexity
Coordinated deployments
Cross-team coupling

Sometimes duplicating the model protects service autonomy.

In this case, duplication is intentional decoupling.

That is mature DRY thinking.

Why DRY Matters Even More Now

Today software complexity is exploding:

Distributed systems
Cloud-native infrastructure
CI/CD pipelines
AI-generated code
Rapid iteration cycles

AI tools, in particular, tend to generate repetitive patterns.

Without strong architectural discipline, systems accumulate silent duplication of knowledge.

The consequences:

Business rules drift apart
Bugs appear inconsistently
Teams lose confidence in behavior predictability

DRY becomes less about code aesthetics and more about organizational coherence.

Where DRY Fails in Practice

There are common failure patterns:

1. Premature Abstraction

Developers abstract after noticing two similar implementations.

But two instances are not a pattern.

The Rule of Three exists for a reason.

Abstraction before stabilization creates rigid design.

2. Over-Centralization

Putting too much logic in a single shared module.

Now every change becomes high-risk.

Instead of reducing complexity, you concentrate it.

3. Accidental Coupling

Shared utility libraries across services.

Seems efficient.

But now one small change triggers a cascade of updates.

DRY at the code level.
Tight coupling at the system level.

4. Confusing DRY with Reusability

Reusability is a possible outcome of DRY.

It is not the definition.

DRY is about knowledge consistency.
Reusability is about convenience.

They overlap, but they are not identical.

A Practical Scenario

Let’s say you’re building an e-commerce platform.

You have:

Checkout service
Promotion engine
Tax calculation module

The tax rule is identical across all flows.

Should you duplicate the tax formula in each service?

No.

Because tax calculation is a business invariant.

It must have one authoritative definition.

Now consider discount logic.

Promotions in checkout may differ from internal admin simulation tools.

They look similar.

But they evolve independently.

Forcing them into a shared abstraction may slow down both teams.

The correct DRY decision depends on:

Stability of the rule
Frequency of change
Organizational structure
Risk tolerance

This is engineering judgment.

Not dogma.

DRY and Engineering Maturity

DRY is not about writing less code.

It’s about designing systems that:

Avoid inconsistent behavior
Protect business rules
Scale without logical divergence

But it requires restraint.

Blind DRY leads to over-engineering.
Ignoring DRY leads to entropy.

The real skill lies in balance.

And that balance is what turns a developer into an engineer.

Final Thought

DRY is not a rule to apply mechanically.

It is a lens to examine how knowledge flows through your system.

When applied correctly:

It reduces systemic fragility.
It improves maintainability.
It increases trust in behavior consistency.

When applied blindly:

It creates tight coupling.
It freezes evolution.
It increases cognitive overhead.

So next time you see duplication, don’t rush to refactor.

Pause.

And ask:

Are these two pieces of code the same knowledge, or just similar shapes?

That answer will define the quality of your system.

And your level as an engineer.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

KISS: The Principle That Turns a Junior into a Real Engineer

Walter Nascimento — Wed, 11 Feb 2026 11:22:50 +0000

If you're at that stage where you're no longer just “writing code” but starting to think about architecture, trade-offs, and maintainability, this article is for you.

KISS is not just a catchy acronym.
It’s a maturity filter.

Where Did KISS Come From?

The KISS principle emerged in the 1960s, in the context of aerospace and military engineering — not software.

It is attributed to Kelly Johnson, the lead engineer at Lockheed Skunk Works, the division responsible for projects like the legendary SR-71 Blackbird.

The original phrase:

“Keep it simple, stupid.”

The word “stupid” was not an insult.
It was a design constraint.

The idea was simple:

A system should be simple enough to be maintained by an average person, under pressure, in real-world conditions.

The Real Problem He Was Solving

The aircraft built by Skunk Works needed to:

Be repaired in the field
With basic tools
By non-specialist technicians
In hostile and urgent conditions

Kelly Johnson imposed a strict rule:

If it cannot be easily explained, maintained, and repaired, the design is wrong.

Complexity = risk.
In aviation, risk = death.

Now replace “aircraft” with “production system.”

How This Applies to Software

Decades later, software engineers realized they were making the same mistake:

“Brilliant” systems no one understands
Beautiful architectures that collapse under change
Codebases that become unmaintainable after 6 months

KISS became one of the foundational principles of software engineering.

But here’s the key difference between a junior and someone becoming mid-level:

Juniors try to prove how much they know.
Mid-level engineers try to reduce complexity.

KISS in Practice (With Python Examples)

Let’s move from theory to code.

Example 1 — Premature Abstraction

❌ “Architectural” Solution

class PriceCalculatorStrategy:
    def calculate(self, price):
        raise NotImplementedError


class DefaultPriceCalculator(PriceCalculatorStrategy):
    def calculate(self, price):
        return price * 1.2


class CheckoutService:
    def __init__(self, strategy: PriceCalculatorStrategy):
        self.strategy = strategy

    def final_price(self, price):
        return self.strategy.calculate(price)

Looks clean.
Feels “enterprise.”

But what if the system only needs one tax rule?

✅ KISS Version

def calculate_final_price(price):
    TAX_RATE = 1.2
    return price * TAX_RATE

Until you actually need multiple strategies, this is:

Clearer
Faster to modify
Easier to debug

KISS doesn’t reject design patterns.

It rejects patterns without problems.

Example 2 — Clever vs Clear

❌ Clever (but confusing)

result = [x for x in data if x % 2 == 0 and x > 10 and str(x).startswith("2")]

Compact? Yes.
Readable? Debatable.

✅ KISS Version

def is_valid_number(x):
    return x % 2 == 0 and x > 10 and str(x).startswith("2")


result = [x for x in data if is_valid_number(x)]

Now:

Logic is reusable
Easier to test
Easier to explain

KISS often means naming things properly instead of compressing them.

The Shift From Junior to Mid-Level

Here’s what changes in your thinking:

Junior mindset:

“How can I make this elegant?”

Growing engineer mindset:

“How can I make this obvious?”

You start asking:

Will someone understand this at 3AM?
Am I solving a real problem?
Is this abstraction justified today?

That’s professional maturity.

The Most Important Line

Code is read far more often than it is written.

If your code is not obvious, it is expensive.

Simple code:

Reduces onboarding time
Reduces bugs
Reduces cognitive load
Reduces ego-driven architecture

Final Thought

Next time you are about to add:

One more abstraction
One more layer
One more pattern

Ask:

Does this solve a real problem right now?

If not, you might be violating KISS.

Simplicity is not lack of skill.
It is controlled intelligence.

And that is what separates someone who writes code
from someone who builds systems.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

What is an API? A Technical and Fun Explanation 🍽️🤖

Walter Nascimento — Wed, 20 Nov 2024 12:37:16 +0000

APIs are everywhere! Whether you're using apps to order food, watch videos, or check the weather, you're interacting with APIs, often without realizing it. But what exactly is an API? In this article, we’ll explain the concept technically and then illustrate it with simple and fun examples, like helper robots or waiters in a restaurant. Let’s dive in! 🚀

What is an API?

Technical Explanation

API stands for Application Programming Interface. In technical terms, it is a set of rules that defines how different systems or applications can communicate and exchange information.

APIs act as "bridges" between systems, enabling them to connect without needing to understand how the other works internally. They handle requests (data or action queries) and responses (data or confirmation results).

How Does it Work?

A system sends a request to the API.
The API processes the request and responds with the data or the result of the action.

For example, when you want to see a random cat image, you can make a request to The Cat API:

Request: GET https://api.thecatapi.com/v1/images/search
Response:

[
  {
    "id": "mtz9",
    "url": "https://cdn2.thecatapi.com/images/mtz9.jpg",
    "width": 500,
    "height": 375
  }
]

This API call returns a random image of a cat, which the app can then display to you. This clear, standardized format allows the app to communicate with The Cat API to fetch data in a way that both systems understand.

Simplifying: How Does it Work in Real Life?

Now that we’ve covered the basics, let’s imagine two simple scenarios to explain APIs in a more relatable way.

APIs as Helper Robots 🤖

Imagine you’re playing with a friend and want a blue piece from their toy set. Instead of rummaging through their toy box, you ask a helper robot to get it for you.

You tell the robot: "Bring me a blue piece!"
The robot understands your request, goes to your friend's toy box, and brings the piece to you.

The robot is the API. It acts as a bridge between you and your friend’s toy box, fetching what you need without you having to dig through the box. Similarly, an API connects two systems and exchanges information without revealing how the other side works.

A real-world example? When you log in to a website using your Google account, the site uses an API to ask Google for the information it needs to authenticate you.

APIs as Waiters in a Restaurant 🍴

Now, imagine you’re at a restaurant and want to order a pizza. You can’t go into the kitchen, so you talk to the waiter:

You say: "I’d like a pepperoni pizza, please!"
The waiter writes down your order and takes it to the kitchen.
The kitchen prepares the pizza, and the waiter brings it to you.

The waiter is like an API. They are the intermediary that translates your request into something the kitchen (the system) understands and then brings the result back to you.

This concept applies to any digital integration. For example, when you order food via a delivery app, it uses APIs to connect to restaurants and display your order on your screen.

Conclusion 🎯

APIs are essential in the digital world, connecting systems and applications efficiently. While they might seem complex from a technical perspective, their role is simple and straightforward: to act as an intermediary between systems, facilitating the exchange of information.

Whether as a helper robot fetching toys or a waiter taking your order, APIs make digital interactions seamless and practical. Next time you use an app, remember—there’s an API working behind the scenes to make it all possible! 🌐

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

PHPStan: Improve the Quality of Your PHP Code

Walter Nascimento — Mon, 09 Sep 2024 11:14:29 +0000

What is PHPStan?

PHPStan (PHP Static Analysis Tool) is a tool that analyzes PHP code to find bugs and issues without executing it. It does this by examining the source code and checking for inconsistencies, such as incorrect variable types, method calls on null objects, and other common mistakes. This is done through static analysis, which is the examination of code without executing it.

Installing PHPStan

To get started with PHPStan, you need to install it in your project. The most common way to install PHPStan is via Composer. Follow these steps to install it:

Install PHPStan via Composer

Open a terminal and run the following command to add PHPStan as a development dependency to your project:

composer require --dev phpstan/phpstan

The --dev flag ensures that PHPStan is installed as a development dependency only.

Verify the Installation

After installation, you can verify if PHPStan was installed correctly by running:

vendor/bin/phpstan --version

This should display the installed version of PHPStan.

Configuring PHPStan with `.neon` File

PHPStan can be configured using a .neon configuration file. This file allows you to define rules, configure analysis levels, and tailor the analysis to your specific project needs.

Basic `.neon` Configuration File

Here is a basic example of PHPStan configuration using a .neon file:

parameters:
    level: 7
    paths:
        - src

Explanation of Configurations

level: Defines the rigor level of the analysis. 7 is quite strict, but you can adjust it as needed.
paths: Defines the directories PHPStan should analyze. In the example, the src directory is analyzed.

Creating Configuration Files for the Team and Ignoring Personal Configurations in Git

It’s a good practice to create a general configuration file for the team and add a .gitignore to avoid versioning personal configurations.

Create a general project configuration file, for example, phpstan.neon:

includes:
    - phpstan.dist.neon

parameters:
    level: 6

    ignoreErrors:
        - '#Attribute class JetBrains\\PhpStorm\\Pure does not exist#'
        - '#Attribute class JetBrains\\PhpStorm\\NoReturn does not exist#'

And a team-specific configuration file, for example, phpstan.dist.neon:

parameters:
    level: max
    paths:
        - src

Add personal configuration files to .gitignore to keep them out of version control:

phpstan.neon

How to Run PHPStan

Once PHPStan is installed and configured, you can run it to analyze your code. Here are the basic commands to run PHPStan:

Run Analysis

To run a basic analysis using the default configuration (your phpstan.neon file), use the following command:

vendor/bin/phpstan analyse

This command performs static analysis of your PHP code as defined in the .neon configuration file.

Run Analysis with Specific Configuration

If you have multiple configuration files and want to specify which one to use, you can use the --config option:

vendor/bin/phpstan analyse --config=phpstan-team.neon

This command allows you to choose which configuration to apply during the analysis.

Check Analysis Levels

PHPStan allows you to set rigor levels from 0 to 8. Higher levels provide more stringent analysis. To run the analysis with a specific level, you can set the level directly in the command:

vendor/bin/phpstan analyse --level=max

The max level is the most stringent, and you can replace max with a specific number as needed.

Example of Before and After

Original Code (Before)

Consider the following PHP code that manipulates a user array:

function getUserAge(array $user): int {
    return $user['age'];
}

$user = [
    'name' => 'John Doe',
    // 'age' is missing
];

$age = getUserAge($user);
echo "User age: $age";

PHPStan Analysis

When PHPStan analyzes the above code, it may point out that the age index is missing in the $user array, but the code tries to access it directly. This could lead to a runtime error if the age index is not present in the array.

Adjusted Code (After)

To fix this and meet PHPStan’s expectations, you can adjust the function to check if the age index is present before accessing it:

function getUserAge(array $user): int {
    if (!isset($user['age'])) {
        throw new RuntimeException('Age is not set in the user array');
    }

    return $user['age'];
}

$user = [
    'name' => 'John Doe',
    // 'age' is still missing, but now the code throws an exception if it’s missing
];

try {
    $age = getUserAge($user);
    echo "User age: $age";
} catch (RuntimeException $e) {
    echo "Error: " . $e->getMessage();
}

Explanation of Changes

Index Existence Check: Adds a check to ensure the age index is present in the array before accessing it.
Exception Handling: Throws an exception if the age index is missing and handles the exception when calling the function.

Conclusion

PHPStan is a powerful tool for improving the quality of your PHP code through static analysis. Installing it is simple and quick with Composer. Configuring it correctly and adjusting its rules can help you find and fix issues before they become real bugs. Use the .neon file to customize PHPStan’s configuration, and remember to add personal configuration files to .gitignore to keep your repository clean and organized.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

PHP_CodeSniffer: Detect code standards violations

Walter Nascimento — Fri, 06 Sep 2024 08:20:28 +0000

PHP_CodeSniffer (PHPCS) is a widely used tool to ensure that PHP code follows coding standards like PSR-12, among others. In this article, learn how to install PHP_CodeSniffer locally, globally, and in Docker, set PSR-12 as the default, configure your project to report errors, automatically fix issues with PHPCBF, and use XML reports.

Installing PHP_CodeSniffer

Local Installation via Composer

To install PHP_CodeSniffer for a specific project, run the following command in your project's root directory:

composer require --dev "squizlabs/php_codesniffer=*"

This installs PHP_CodeSniffer as a development dependency in your project.

Global Installation via Composer

To use PHP_CodeSniffer across multiple projects, you can install it globally:

composer global require "squizlabs/php_codesniffer=*"

After global installation, ensure the directory ~/.composer/vendor/bin is in your PATH. Add the following line to your ~/.bashrc (or ~/.zshrc for Zsh users):

export PATH="$PATH:$HOME/.composer/vendor/bin"

Then reload your shell configuration:

source ~/.bashrc

Installation with Docker

If you're using Docker, you can include PHP_CodeSniffer in your image. Here's an example Dockerfile:

FROM php:8.1-fpm

# Install Composer and PHP_CodeSniffer
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer global require "squizlabs/php_codesniffer=*"

# Configure the PATH
RUN echo 'export PATH="$PATH:$HOME/.composer/vendor/bin"' >> $HOME/.bashrc

CMD ["php-fpm"]

This configuration ensures that PHP_CodeSniffer is globally available when you run the container.

Setting the PSR-12 Standard

PSR-12 is the recommended coding standard by PHP-FIG for PHP code formatting. To set PHP_CodeSniffer to use PSR-12, run the following command:

phpcs --standard=PSR12

Alternatively, configure it in your phpcs.xml file:

<?xml version="1.0"?>
<ruleset name="PSR12 Coding Standard">
    <rule ref="PSR12"/>
    <file>src/</file>
</ruleset>

Using the XML Configuration File

You can customize PHP_CodeSniffer with an XML configuration file, allowing you to disable certain checks, add features like progress bars, and color output.
Example of phpcs.xml:

<?xml version="1.0"?>
<ruleset name="Custom Coding Standards">
    <description>PHPCS Custom Ruleset Example</description>

    <!-- PSR-12 Standard -->
    <rule ref="PSR12"/>

    <!-- Color the result output -->
    <arg name="colors" />

    <!-- Show progress of the run -->
    <arg value="ps" />

    <!-- Code directory -->
    <file>src/</file>

    <!-- Ignore file and class comment errors -->
    <rule ref="Squiz.Commenting.FileComment.Missing">
        <exclude-pattern>*/src/*</exclude-pattern>
    </rule>
    <rule ref="Squiz.Commenting.ClassComment.Missing">
        <exclude-pattern>*/src/*</exclude-pattern>
    </rule>
</ruleset>

Now, when you run the command, you'll see a progress bar and colored output in the terminal, along with using the PSR-12 standard.

Code Example: Before and After PHPCBF

Original Code (Before)

<?php
namespace MyApp;

class MyClass {
    public function myFunction() {
        $var = "Hello World!";
        echo $var;
    }
}

After Running PHPCBF

To automatically fix issues found by PHP_CodeSniffer, use the following command:

phpcbf --standard=PSR12 src/MyClass.php

Corrected Code (After)

<?php

namespace MyApp;

class MyClass
{
    public function myFunction()
    {
        $var = "Hello World!";
        echo $var;
    }
}

PHPCBF automatically corrects the formatting to conform with the PSR-12 standard by adjusting indentation, spacing, and proper bracket placement.

Generating a Summary XML Report

PHP_CodeSniffer can generate a summary XML report, which is useful for CI/CD pipelines or automated code analysis.
Configuring XML Summary Reports

To configure PHP_CodeSniffer to generate a summary XML report, add the following configuration to your phpcs.xml file:

<?xml version="1.0"?>
<ruleset name="Custom Coding Standards with Summary">
    <rule ref="PSR12"/>

    <!-- Generate a summarized XML report -->
    <arg name="report" value="summary"/>
    <arg name="report-file" value="phpcs-summary.xml"/>

    <file>src/</file>
</ruleset>

When you run phpcs, it will generate a phpcs-summary.xml file that contains a summary of the violations found.

Conclusion

PHP_CodeSniffer is a powerful tool for ensuring PHP code quality, allowing you to follow coding standards like PSR-12 and customize your checks using an XML configuration file. With it, you can automate code style correction and generate useful reports for reviews and continuous integration.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Code Improvements

Walter Nascimento — Wed, 08 May 2024 22:30:19 +0000

Code optimization is essential for maintaining efficient and manageable software projects. This article explores practical techniques for improving the readability and maintainability of PHP code, presenting concrete "before" and "after" examples for each technique discussed.

Using Formatting Tools

To ensure consistency in formatting, tools like .editorconfig are essential.

Example:
Before:

function calculate($x,$y) { return $x+$y; }

After:

function calculate($x, $y) {
 return $x + $y;
}

Code Comment and Removal of Unused Items

In addition to removing commented code, it is essential to eliminate unused variables and functions, which clarifies the purpose of the active code.

Example:
Before:

// Calculate the total 
function calculateTotal($items) {
 $x; // Old unused variable
 return array_sum(array_column($items, 'price'));
}

After:

function calculateTotal($items) {
 return array_sum(array_column($items, 'price'));
}

Implementation of "Early Return"

Reduces complexity by avoiding excessive nesting, using early returns.

Example:
Before:

function isEligible($age) {
 if ($age > 18) {
 return true;
 } else {
 return false;
 }
}

After:

function isEligible($age) {
 return $age > 18;
}

Use of the Ternary Operator

The ternary operator allows you to write conditions more concisely and clearly, reducing the number of lines of code.

Example:
Before:

function getStatus($user) {
 if ($user->isActive()) {
  return 'Active';
 } else {
  return 'Inactive';
 }
}

After:

function getStatus($user) {
 return $user->isActive() ? 'Active' : 'Inactive';
}

Reducing the Use of "else"

Eliminating "else" after "if" simplifies the logic.

Example:
Before:

if ($condition) {
 performAction();
} else {
 handleAlternative();
}

After:

if ($condition) {
 performAction();
 return;
}
handleAlternative();

Simplifying Nested Conditions

Simplify nested conditions into a single expression.

Example:
Before:

if ($user->isActive) {
 if ($user->age >= 18) {
 approveUser($user);
 }
}

After:

if ($user->isActive && $user->age >= 18) {
 approveUser($user);
}

Efficient Use of Model Data

Load only the necessary data from a model.

Example:
Before:

$dataIni = Yii::$app->request->post('Banner')['dataIni'];
$dataFim = Yii::$app->request->post('Banner')['dataFim'];

After:

$bannerPost = Yii::$app->request->post('Banner');
$dataIni = $bannerPost['dataIni'];
$dataEnd = $bannerPost['dataEnd'];

Replacing Depreciated Items

Update class or method references to avoid obsolescence.

Example:
Before:

$class = AccessControl::className();

After:

$class = AccessControl::class;

Avoid Magic Numbers

Replace arbitrary numbers with named constants.

Example:
Before:

if ($user->age >= 18) {
 approveUser($user);
}

After:

const MIN_AGE_FOR_APPROVAL = 18;
if ($user->age >= MIN_AGE_FOR_APPROVAL) {
 approveUser($user);
}

Preference for "foreach" over "for"

Use simpler and clearer iteration structures.

Example:
Before:

for ($i = 0; $i < count($users); $i++) {
 echo $users[$i]->name;
}

After:

foreach ($users as $user) {
 echo $user->name;
}

Modularization of Functions

Break large functions into smaller functions to make it easier to understand.

Correct Use of Private Functions

Set internal-use functions to private to protect and organize code.

Use Pass-by-Reference Where Appropriate

Encourage the use of pass by reference in situations where large objects or collections of data are manipulated frequently. This can significantly reduce memory overhead and increase application performance.

Example:
Before:

function modifyItem($array, $index, $newValue) {
 $array[$index] = $newValue; // Modification is local
 return $array; // Need to return the modified array
}
$myArray = [1, 2, 3];
$myArray = modifyItem($myArray, 1, 20); // Reassignment required
print_r($myArray);

💡 NOTE: In this case, the modifyItem function needs to return the modified array, and then the original array must be reassigned with this new returned value, which implies more intensive memory management.

After:

function modifyItem(&$array, $index, $newValue) {
 $array[$index] = $newValue; // The modification affects the original array directly
}
$myArray = [1, 2, 3];
modifyItem($myArray, 1, 20); // No reassignment required
print_r($myArray);

💡 NOTE: Here, the modifyItem function uses the & symbol in the $array parameter to indicate that the array is passed by reference. This means that any modification to the array within the function will directly affect the original array without the need to return and reassign it. The modification is done directly in the memory where the original array is stored, saving resources and simplifying the code.

Using the Null Coalesce Operator in PHP

The null coalesce operator (??) is a useful addition to PHP that helps you write cleaner, more efficient code when dealing with values that can be null. This operator is especially useful for simplifying the assignment of default values to variables that may not be defined or that may contain a null value.

Example:
Before:

$username = isset($_GET['username']) ? $_GET['username'] : 'guest';

After:

$username = $_GET['username'] ?? 'guest';

Conclusion

By implementing these practices, developers ensure that code is clean, efficient, and easy to understand, making both maintenance and collaboration on software projects easier.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!

😊😊 See you later! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso