Defusing the IF-Strategy
Begin your Anti-IF journey by expressing support and exploring the foundational principles. Ideal for enthusiasts eager to dip their toes into the world of condition-free programming.
Learn moreElevate your skills by diving deeper into Anti-IF strategies. Command your codebase with increased proficiency and navigate the complexities of real-world applications.
Learn moreReign supreme in the realm of Anti-IF programming. As a Boolean Sovereign, you've achieved mastery, showcasing unparalleled expertise and leading the charge against the rise of the Code Monsters.
Learn moreOriginated by Francesco Cirillo in 2007, the Anti-IF Programming approach has transformed how many perceive IFs and conditionals in software design. Explore its history. On this page, we delve into the essence of this approach.
The IF Dilemma
At the heart of software design lies a simple yet potentially dangerous tool: the conditional 'IF' statement. Undeniably foundational, its use to handle changes in a growth context, dubbed the "IF Strategy", can be a silent saboteur, complicating code and tangling logic. The IF Strategy can lead to debugging problems, never-delivered user stories, technical debt, entangled design, frictions in the team and other inefficiencies. In essence, the IF Strategy can escalate costs and delay software delivery times while degrading internal quality.
The Pitfalls of the "IF Strategy"
Why do developers opt for the IF Strategy when faced with changes? Simply put, it's the most immediate or primitive approach.
Suppose a statement performs a specific action, and there's a desire for it to function differently under certain conditions. The immediate solution might be to add a conditional, such as an IF or a switch, around that statement and introduce an alternative action. The job seems done.
This solution appears efficient in the short term, considering the time to implement the change. If the software never changed again, the IF Strategy would be ideal. But software constantly changes and evolves. Like a snowball gathering momentum, an over-reliance on this strategy can quickly blur logic, diminish code readability, and undermine its maintainability and testability. Nested IFs, in particular, can confuse even the most seasoned developers and bring in duplications and bugs. In the ever-changing landscape of software development, the IF Strategy can lead to catastrophic consequences, especially as the software grows—making it a poor choice when considering long-term repercussions.
Often, the choice of the IF strategy arises from time pressures: "The deadline is tomorrow; how do we make this change?" But frequently, it also stems from a lack of design knowledge. Many developers are unaware of how to implement a change using a design solution different from the IF Strategy. In both scenarios, opting for the IF Strategy means overlooking alternative solutions.
Defusing the IF Strategy requires training, and that's where Anti-IF Programming steps in. It serves as a training tool, ensuring that even under time pressures, developers take a moment to reflect and evaluate a series of valuable design alternatives for software growth instead of defaulting to the IF Strategy.
The Promise of Anti-IF Programming
Anti-IF Programming isn't advocating for the outright abandonment of 'IF' statements. Instead, it champions their mindful use, particularly in software growth scenarios. This philosophy urges developers to explore alternative design methods, ones skilled at addressing growth, change, and complexity, without succumbing to the pitfalls of the "IF Strategy."
By steering clear of an excessive maze of conditionals, developers can embrace patterns, polymorphism, and other robust strategies. The result? A codebase that's flexible, adaptable, and easy to test—a place where errors are minimised, comprehension is amplified, and maintenance is streamlined.
Conclusion
Anti-IF Programming serves as a guiding light, steering developers toward neater, more intuitive coding practices. It's an open invitation to rise above conventional challenges and traverse the complex world of software development with clarity and assurance.
Simplify your codebase by removing excessive nested conditions and redundancies, making it easier to navigate and modify.
Enhance the clarity of your code with consistent structuring and naming conventions, allowing both novice and expert developers to understand its flow quickly.
By reducing complexity and promoting best coding practices, experience a significant drop in software defects and logic errors, ensuring a more robust application.
Design your software to handle evolving requirements gracefully. This resilience means less overhaul and rework when changes arise.
With a combination of streamlined code and a clear design, accelerate your software development cycle, enabling quicker releases and feature updates.
Achieve a trifecta of software development. By emphasizing efficiency and effectiveness, deliver high-quality software promptly without breaking the budget. This benefit arises from the cumulative effects of the points above.
Have you ever wondered how IFs impact on your code?
Lot of developers apply the "IF Strategy" to deal with growth, change and complexity:
IF ( new condition) { new code }
Unfortunately, by doing that regularly, they increase the complexity of their software system. As a consequence, the next changes will cost more and more!
The goal of the Anti-IF Programming is to raise awareness of the risks of applying the "IF Strategy" and to draw attention to the importance of replacing it with other design techniques, more effective to deal with growth, change and complexity. Defusing the "IF Strategy" enables developers to get a code that is flexible, changeable and easily testable. This will help to avoid a lot of headaches and weekends spent debugging!
...about a software developer working in a company who was building up a nice platform. One day the boss calls the developer on the phone and says: "There’s a new task I need you to do for a really important client, and it must be done by the end of the day. All that’s needed," the boss continues "is to add a small piece of functionality to that class method you’ve been working on... it shouldn’t be too complex..."
The days go by...
and that small class, edit by edit, grows into a small code monster: the more you feed it with IFs, the bigger it grows!
Do you think it’s just a fairy tale?
Well, it’s not!
What follows below is a single class method taken from real code that is live on a server somewhere on the Internet right now. And this is just a "baby monster". The more you feed it, the bigger it grows!
calculateWageFor(Person aPerson) { ... IF=> IF(aPerson.type == Person.EMPLOYEE) { ordinaryHourlyWage = 15; overtimeHourlyWage = 20; IF=> IF(aPerson.status == Person.PARENTALLEAVE) { ordinaryHourlyWage= ordinaryHourlyWage * .70; // 70% IF=> IF(aPerson.daysOffLeft() > 10) { ordinaryHourlyWage = ordinaryHourlyWage * 0.9; // 90% } } salary = aPerson.ordinaryWorkHours * ordinaryHourlyWage + aPerson.overtimeWorkHours * overtimeHourlyWage; } IF=> IF(person.type == Person.MANAGER) { fixedWage = 3000; monthlyBonus = lastYearsProfit * .10 / 12; // 10% monthly IF=> IF(aPerson.status == Person.PARENTALLEAVE) { monthlyBonus= monthlyBonus * .60; // 70% IF=> IF(aPerson.daysOffLeft() > 10) { fixedWage = fixedWage * 1; // 90% monthlyBonus= monthlyBonus * 1; // 70% } } salary = fixedWage + monthlyBonus; } IF=> IF(person.type == Person.CONSULTANT) { dailyFee = 300; workHours = aPerson.workHours(); realDays = workHours / 7; salary = realDays * dailyFee; } return salary; }
Pretty scary,huh?
Yes, it is.
And it happens everyday all over the web.
So, what can I do to help?