As software engineers, we often face the challenge of balancing code readability with maintainability. One concept that helps navigate this balance is the Rule of Three. This rule, popularized by Martin Fowler in his book Refactoring, offers a practical guideline: "Three strikes and you refactor."

What is the Rule of Three?

The Rule of Three suggests that you should refactor your code when you find yourself writing similar code for the third time. The idea is straightforward: writing the same code once is acceptable, and twice might still be fine, but the third time is your cue to extract the repeated code into a new procedure or function. This helps avoid redundancy and makes your code more maintainable.

Why is Duplication a Problem?

Duplicated code can lead to several issues:

• Increased Maintenance Effort: If a bug is found in one instance, you need to fix it everywhere the code is duplicated.
• Consistency Issues: Changes in business logic or requirements need to be applied consistently across all duplicated code, increasing the risk of errors.
• Code Bloat: Duplicated code makes the codebase larger and harder to navigate. By refactoring duplicated code into a single function, you centralize the logic, making your codebase leaner and easier to maintain.

But Why Wait Until the Third Instance?

It might seem counterintuitive not to refactor after the second instance of duplication. However, premature refactoring can lead to selecting the wrong abstraction. As Sandi Metz points out in her article "The Wrong Abstraction", refactoring too early can result in a design that doesn't fit future requirements, leading to more complications and potentially even worse code. Waiting until the third instance provides enough context to identify a more appropriate abstraction. By then, you can better understand the common patterns and requirements, making your refactoring efforts more effective and robust.

Practical Application

Imagine you're working on a feature that requires similar logging in multiple places. The first time you write the logging code, it's fine to leave it as is. The second time, you might copy and paste it again, but keep an eye on it. The third time, it's clear that this logging is a common requirement. This is your signal to refactor this code into a single logging function.

Conclusion

The Rule of Three provides a practical balance between avoiding unnecessary duplication and premature abstraction. By adhering to this rule, you can keep your codebase maintainable without falling into the trap of over-engineering. For more insights, check out Martin Fowler's Refactoring: Improving the Design of Existing Code and Sandi Metz's article, "The Wrong Abstraction".

Happy coding!