Hey dev community!

Today, I want to talk about something we’ve all encountered at some point: redundant code. It might seem harmless in small doses, but letting it slip through your fingers can result in bloated, inefficient code that’s harder to maintain. So, let's dive into a principle that has saved me countless headaches—DRY (Don't Repeat Yourself).

DRY is one of those foundational principles in software development that helps you keep your code clean, readable, and maintainable. Its core message is simple: avoid redundancy. The more you repeat yourself, the more you increase the likelihood of bugs, inconsistencies, and future maintenance nightmares.

Let me show you a real-world example of how applying DRY can improve your code quality. I was refactoring a method that looked like this:

private List<RhpBEEarning> GetContractEarningsForPeriod(string contract, DateTime startDate, DateTime endDate)
{
    var result = new List<RhpBEEarning>();

    var earnings = m_objErpBSO
        .LstCadastroHorasExtraFuncDatasEx(contract, startDate, endDate)
        .Where(p => p.Origem == C_IDORIGEM_VT)
        .ToList();

    // Add earnings to result
    result.AddRange(earnings);

    return result;
}

At first glance, this method looks fine. It gets the job done, but there’s an underlying issue here—redundancy.

The Problem

Notice how we’re creating an empty result list and then adding all the elements from earnings to it? This is redundant. We don’t need an empty list, only to fill it later. The method could be more direct and easier to read by cutting out that unnecessary step.

In essence, this breaks the DRY principle. Instead of creating a list, filling it, and then returning it, why not just return the result directly?

*The Refactor *

Here’s the cleaner version of the same method:

private List<RhpBEEarning> GetContractEarningsForPeriod(string contract, DateTime startDate, DateTime endDate)
{
    return m_objErpBSO
        .LstCadastroHorasExtraFuncDatasEx(contract, startDate, endDate)
        .Where(p => p.Origem == C_IDORIGEM_VT)
        .ToList();
}

Boom! Just like that, we’ve eliminated the redundancy.

Why Does This Matter?

1. Clarity: The second method is much easier to read. When you look at it, you know exactly what it’s doing—fetching data, filtering it, and returning it as a list. No unnecessary steps in between.

2. Maintenance: The fewer steps you have in your code, the fewer places bugs can hide. Imagine revisiting the first version six months later and trying to understand why you needed that result list. Clean code is easier to maintain and modify.

3. Performance: While the performance gains in this case are minimal, eliminating unnecessary operations (like creating an empty list and then adding to it) can add up, especially in larger systems.

Keep it DRY

The DRY principle might seem like a small detail, but it makes a huge difference in the long run. Redundancies can sneak in when we’re focusing on making things work, but taking the time to clean them up afterward is crucial for writing maintainable, clean code.

Next time you find yourself repeating patterns or steps unnecessarily, ask yourself: Is this the most direct, efficient way to accomplish this? If not, it might be time to refactor and DRY it up!

Hope this helps! Let me know your thoughts or any DRY refactors you’ve done recently.

Happy coding!