Latitude 40 Blog

Clean Code: Mindset Over Dogma

9/18/2025

Developer is sitting at her desk with multiple monitors thinking about the design of a software system she's helping write.

Lately, I've seen a wave of criticism and developer backlash against clean code. They argue it's too rigid, too idealistic, and often counterproductive. They point to over-engineered systems filled with tiny methods, excessive abstraction, and unnecessary complexity, all in the name of "clean code."

But this criticism often confuses the mindset with its misapplication. Clean code isn't a checklist or a burden. It's a way of thinking about how your code will be understood, maintained, and extended by others.

The Mindset vs. the Mechanics

Clean code is not a set of rules to follow blindly. It's a mindset with a commitment to clarity, maintainability, and empathy for the next developer. The techniques commonly associated with clean code (like meaningful naming, small functions, and separation of concerns) are tools that support this mindset. They're not mandates.

When developers apply these techniques without understanding the why, they risk creating code that's technically "clean" but practically unreadable. The mindset encourages thoughtful application, not dogmatic adherence.

Why It Matters in the Enterprise

In enterprise environments, code lives longer, changes hands more often, and supports critical systems. Maintainability is a necessity. Clean code helps teams avoid technical debt, reduce onboarding time, and improve collaboration.

Even if you don't apply every principle, understanding the mindset helps you make better decisions. It's not about perfection. It's about writing code that others can work with confidently.

Clean Code Is Empathy in Action

At its core, clean code is about empathy. It's about writing software that respects the time and effort of others. It's about leaving behind code that's easy to read, change, and build upon.

This mindset fosters trust, reduces bugs, and makes teams more resilient. It's not just about how the code looks, it's about how it feels to work with.

Conclusion: Don't Reject the Mindset

Let's be clear: you absolutely shouldn't reject the clean code mindset. If you choose to skip the education and experience that comes from practicing clean code, you're not just avoiding a style. You’re limiting your growth as a developer.

Clean code principles teach you how to think about architecture, readability, and long-term maintainability. These are the skills that separate good developers from great ones. They're far more important than knowing the latest language features or syntax tricks.

Languages change. Frameworks evolve. But the ability to write code that others can understand, maintain, and extend is timeless.

About Latitude 40

Latitude 40 helps businesses achieve operational excellence and long-term business agility through tailored software solutions and expert guidance. By embedding into client teams, Latitude 40 delivers elegant, maintainable software while teaching Agile practices that foster sustainable growth. Latitude 40 builds with clarity, purpose, and a deep respect for the people who maintain and evolve code.

Need help cleaning up a messy codebase or modernizing your systems? Let’s talk.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned software architect with over two decades of experience in Agile delivery. He's worked globally as a developer, analyst, and instructor, and is passionate about writing maintainable code and helping teams grow through clean architecture and practical Agile practices. Andrew shares insights from the field to help developers and leaders build better software, and better teams.

0 Comments

Clean Code: Write Code That Explains Itself

8/10/2025

0 Comments

Software developer writing clean code via their laptop

Introduction

In the world of software development, clarity is king. While comments and documentation have their place, the best code is the kind that explains itself. That's the essence of self-documenting code; writing code that's so clear, it barely needs comments.

In this post, we'll look at two simple but powerful techniques to make your code more readable and maintainable.

Naming That Explains

Poorly named variables and methods are one of the fastest ways to make code unreadable. Consider this simple example:


var d = DateTime.Now.AddDays(7);
if (u.IsActive && d > u.Reg)
{
    Send(u);
}

Now compare it to this:


var expirationDate = DateTime.Now.AddDays(7);
if (user.IsActive && expirationDate > user.RegistrationDate)
{
    SendWelcomeEmail(user);
}

Same logic. Vastly improved clarity.

Tips for Better Naming

Use descriptive nouns for variables: invoiceTotal, userEmail, retryCount
Use verbs for methods: CalculateTax(), SendReminder()
Use predicate-style names for boolean methods: IsExpired(), HasPermission(), CanRetry()
Abbreviations are fine when they’re widely understood or when the full name would be unwieldy
Don’t be afraid of longer names if they improve clarity, but use judgment. Sometimes overly long names can hurt readability more than they help

Extracting Logic into Named Methods

Another way to make code self-explanatory is to extract blocks of logic into well-named methods. This not only improves readability but also makes testing and reuse easier.

Before:


if (user.IsActive && DateTime.Now.AddDays(7) > user.RegistrationDate)
{
    SendWelcomeEmail(user);
}

After:


if (ShouldSendWelcomeEmail(user))
{
    SendWelcomeEmail(user);
}

...

private bool ShouldSendWelcomeEmail(User user)
{
    var expirationDate = DateTime.Now.AddDays(7);
    return user.IsActive && expirationDate > user.RegistrationDate;
}

Now the if statement reads like a sentence. The logic is tucked away in a method with a name that explains its purpose.

When Comments Are Appropriate

Self-documenting code reduces the need for comments, but it doesn't eliminate them entirely. Sometimes, the why behind a decision isn’t obvious from the code alone.

Here’s an example where a comment adds value:


// We use a 7-day buffer to account for timezone discrepancies in legacy systems
var expirationDate = DateTime.Now.AddDays(7);

This kind of comment explains why something is done, not what is being done. That distinction is key.

Use comments to:

Explain business rules or domain-specific logic
Justify workarounds or technical debt
Provide context for non-obvious decisions

Avoid comments that:

Repeat what the code already says
Try to explain confusing code that could just be rewritten

The Real Cost of Poor Naming

We recently worked with a client who brought us in to modernize a legacy system riddled with bugs. The biggest challenge? The code was a mess of cryptic variable names, massive methods, and zero structure. Some classes literally had 100,000+ lines of code and if/else nesting 12 levels deep. It was nearly impossible to tell what anything did.

Simple changes like fixing a validation rule or updating a report were taking 10x longer than they should have. Every fix risked breaking something else because the code was so hard to reason about.

The takeaway? Clean code isn't just a nicety. It’s a multiplier for your team's velocity and confidence.

Final Thoughts

Self-documenting code is one of the simplest things you can do to improve your codebase. It's about writing code that's easy to read, easy to change, and easy to trust.

Start with better names. Extract logic into small, focused methods. And when you need to explain a why, leave a thoughtful comment.

Next time you're tempted to write a comment, ask yourself: Can I just make the code clearer instead?

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Need help cleaning up a messy codebase or modernizing your system? Let’s talk.

About the Author

Andrew Anderson is the President of Latitude 40 and a lifelong advocate for clean, maintainable code. With over two decades of experience as a developer, analyst, and Agile coach, he's worked globally to help teams build better software and embrace sustainable delivery practices.

0 Comments

Clean Code: The Strategy Pattern in C#

6/30/2025

0 Comments

Introduction

In software development, writing code is only half the job. The real challenge (and the real cost) comes later, when that code needs to change.

That's why maintainability is one of the most important qualities of a healthy codebase. Clean, modular code reduces bugs, accelerates onboarding, and supports business agility.

One pattern I find myself using frequently is the Strategy Pattern. It's a simple but powerful way to eliminate brittle if/else logic and replace it with clean, extensible design. In this post, I'll walk through a simple yet realistic example of different order pricing models and show how the Strategy Pattern helps us write code that's easier to understand, test, and evolve.

Setting the Stage: Dynamic Pricing Strategy

Let's say you're building a custom order system for a horticulture company. Different clients get different pricing strategies:

Retail customers pay full price.
Retail loyalty customers get a percentage discount.
Wholesale customers get a volume discount based on order volume.

Before: The Classic If/Else Trap


public class PricingService(IWholesaleDiscountRepository wholesaleRepo,
    LoyaltyProgramSettings loyaltyProgramSettings)
{
    public decimal CalculatePrice(Customer customer, Order order)
    {
        if (customer.Type == CustomerType.Retail)
        {
            return order.BasePrice;
        }
        else if (customer.Type == CustomerType.Loyalty)
        {
            return order.BasePrice * (1 - loyaltyProgramSettings.DiscountRate);
        }
        else if (customer.Type == CustomerType.Wholesale)
        {
            var tiers = wholesaleRepo.GetDiscountTiers()
                                      .OrderByDescending(t => t.MinQuantity);

            var discount = tiers.FirstOrDefault(
                t => order.Quantity >= t.MinQuantity)?.DiscountRate ?? 0m;

            return order.BasePrice * (1 - discount);
        }

        throw new InvalidOperationException("Unknown customer type");
    }
}

What's Wrong?

The PricingService is doing too much with its branching logic and different calculations. Real-life scenarios will likely be much more complex too (like wholesale volume discounts are probably based on seasonal order volume, not a single order's volume).
Depending on the complexity of your real-world scenario, you may want to apply the Open/Closed Principal, and that is impossible in this example.
The logic is not modular - you can't reuse or test pricing strategies independently.

After: Strategy Pattern

Let's refactor this using the Strategy Pattern.

Step 1: Define the Strategy Interface


public interface IPricingStrategy
{
    decimal CalculatePrice(Order order);
}

Step 2: Implement Strategies


public class RetailPricingStrategy : IPricingStrategy
{
    public decimal CalculatePrice(Order order) => order.BasePrice;
}

public class LoyaltyPricingStrategy(LoyaltyProgramSettings loyaltyProgramSettings)
    : IPricingStrategy
{
    public decimal CalculatePrice(Order order)
        => order.BasePrice * (1 - loyaltyProgramSettings.DiscountRate);
}

public class WholesalePricingStrategy(IWholesaleDiscountRepository discountRepo)
    : IPricingStrategy
{
    public decimal CalculatePrice(Order order)
    {
        var tier = discountRepo.GetDiscountTiers()
                        .OrderByDescending(t => t.MinQuantity)
                        .FirstOrDefault(t => order.Quantity >= t.MinQuantity);

        var discountRate = tier?.DiscountRate ?? 0m;
        return order.BasePrice * (1 - discountRate);
    }
}

Step 3: Strategy Factory


public interface IPricingStrategyFactory
{
    IPricingStrategy GetStrategy(Customer customer);
}

public class PricingStrategyFactory(IServiceProvider provider)
    : IPricingStrategyFactory
{
    public IPricingStrategy GetStrategy(Customer customer) => customer.Type switch
    {
        CustomerType.Retail
            => provider.GetRequiredService(),
        CustomerType.Wholesale
            => provider.GetRequiredService(),
        CustomerType.Loyalty
            => provider.GetRequiredService(),
        _ => throw new NotSupportedException("Unknown customer type")
    };
}

Step 4: Application Code


public class OrderProcessor(IPricingStrategyFactory pricingStrategyFactory)
{
    public void ProcessOrder(Customer customer, Order order)
    {
        var strategy = pricingStrategyFactory.GetStrategy(customer);
        var price = strategy.CalculatePrice(order);
        ...
    }
}

Conclusion

The Strategy Pattern isn't just a design tool. It's a way to build systems that are easier to understand, extend, and maintain.

In the example above, we started with a data-driven pricing model that worked, but was tightly coupled and procedural. By refactoring with the Strategy Pattern, we separated concerns and made each pricing rule modular.

This kind of architecture pays off in real-world scenarios:

New pricing models can be added without touching existing logic.
Each pricing model can be independently unit tested and verified easier.
Business rules could potentially be loaded from configuration or external sources.
Developers onboard faster and changes are easier/faster, because the code is easier to reason about.

These aren't just technical wins, they're business wins. Clean code reduces risk, accelerates delivery, and supports long-term agility.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Need help modernizing your codebase or designing maintainable systems? Let's talk.

About the Author

Andrew Anderson is the President of Latitude 40 and a seasoned software architect with over two decades of experience in development and Agile delivery. He's worked globally as a developer, analyst, and coach, and is passionate about helping teams build software that is both powerful and maintainable.

0 Comments

Latitude 40 blog

Clean Code: Mindset Over Dogma

The Mindset vs. the Mechanics

Why It Matters in the Enterprise

Clean Code Is Empathy in Action

Conclusion: Don't Reject the Mindset

About Latitude 40

About the Author

Clean Code: Write Code That Explains Itself

Introduction

Naming That Explains

Tips for Better Naming

Extracting Logic into Named Methods

When Comments Are Appropriate

The Real Cost of Poor Naming

Final Thoughts

About Latitude 40

About the Author

Clean Code: The Strategy Pattern in C#

Introduction

Setting the Stage: Dynamic Pricing Strategy

Before: The Classic If/Else Trap

What's Wrong?

After: Strategy Pattern

Step 1: Define the Strategy Interface

Step 2: Implement Strategies

Step 3: Strategy Factory

Step 4: Application Code

Conclusion

About Latitude 40

About the Author

Categories