Why the first instruction we learn to program should be the last to use. Nobody uses anymore and few programming languages still support it. GOTO instruction We have matured and confirmed is unmaintainable and error prone. solved that problem years ago. spaghetti code Structured Programming We got rid of the sentence thanks to ’s incredible : Go To Statement Considered . Edsger Dijkstra paper Harmful Next evolution step will be removing most . IF statements and are disguised as structured flow. IFs/Cases Switches GOTOs Our tool will be Object Oriented Programming principles. Photo by Przemysław Bromberek in Pixabay The Problem Most sentences are coupled to . This coupling generates ripple effect and make code harder to maintain. IF accidental decisions Coupling: The One and Only Software Designing Problem Ifs are considered as as . Harmful GOTOs sentences violate . Our designs will be less extensible and closed to extension. If open/closed principle What is more, are open doors to even worse problems, like , , , , and . Ifs switches cases defaults return continue breaks They make our algorithms darker and force us to build solutions. accidentally complex There Are No Silver Bullets For This Werewolf People out of software development cannot explain why we use this branching sentence. This is a code smell. How to Find the Stinky Parts of Your Code (Part I) Solutions Before we move on and remove IF sentences we should decide if its an one or an If. essential accidental To check this out we will look for answers in real world through bijection. The One and Only Software Design Principle Essential Ifs Let’s see an statement essential IF We should decide whether to remove this or not. if sentence We must understand whether it is represents a business rule ( ) or an implementation artifact ( ). essential accidental In the case above we will honor our . So we will NOT replace the if. bijection People In real world describe age constraints in natural language using IFs Accidental Ifs Let us dive now into bad IFs. The movie rating is not related to a but to accidental (and coupled) implementation. IF real world If Our design decision was to model with . ratings strings This is a classic solution. neither open to extension, nor closed to modification Let’s see what happens with new requirements. We can detect some : Code Smells Code is polluted with . IFs A default statement is missing. New ratings will bring new . IFs The strings representing ratings are not first class objects. A typo will introduce hard to find errors. We are forced to add on to take decisions. getters Movies The Recipe Let’s fix this mess with these steps: 1 — Create a Polymorphic Hierarchy for every IF condition (if it doesn’t already exist). 2 — Move every to the former abstraction. IF Body 3 — Replace IF Call by polymorphic method call. On our example: With this outcome: 1. Code is polluted with IFs We should add no more IFS. Extending the model will be enough. 2. A default statement is missing In this case default behaviour is not needed since exceptions break flow. In many times a Null Object will be enough. 3. New ratings will bring new IFs We will be address it with polymorphic new instances. 4. The strings representing ratings are not first class objects. A typo will introduce hard to find errors. This is hidden in Ratings implementation. 5. We are forced to add getters on to take decisions. Movies We will clear this favoring Demeter’s law. Breaking this collaboration chain: Rating is private so we don’t break encapsulation. As a consequence we are safe to avoid getters. Nude Models - Part II : Getters Applying the recipe to all IF conditions Now we have the secret formula we can go further and try to remove the related to age. essential IF condition We replaced all . In the later case using IFs Double Dispatch Technique We used our formula and it worked. But there’s a smell of . over design Classes representing Ages are not related to real concepts on our . model Model is too complex. We will need new classes related to new age groups. Age groups might not be disjoint. We should avoid the last design and set a between and ifs. clear boundary essential accidental A Good design rule is to create abstractions if they belong to the same domain (movies and ratings) and don’t do it if they cross domains (movies and ages). Do Ifs stink? According to evidence shown above. We should consider many IFs to be a code smell and tackle them with our recipe. Replace Conditional with Polymorphism Why this is happening? This article (and many others) recommend avoiding most This will be very hard for all developers very comfortable with its usage. IF sentences. Remember, Laziness and hidden assumptions are very rooted on our profession. We have been (ab)using for decades and our software is not the best version of it. IFs This is a root cause analysis of a serious SSL defect on IOS caused by a lazy case: Reflections on Curly Braces – Apple’s SSL Bug and What We Should Learn From It This article’s thesis suggests there’s a correlation between and defects. IFs/Switch/Case You should give a try and avoid IF conditionals. Conclusions With this simple technique we will be able to remove, in a procedural way, all accidental ifs. This will make our models less coupled and more extensive. Null object pattern is a special case of this technique. We will be able to remove all NULLs since: NULL ifs are always accidental. NULL: The Billion Dollar Mistake Credits We have been using at for several years. Kudos to all my fellow teachers for all the experience we gathered together with it. If removal technique Universidad de Buenos Aires Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.

Flow

Chain

Apple

How to Find the Stinky Parts of Your Code (Part III)

How to Find the Stinky Parts of Your Code (Part II)

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Too Long; Didn't Read

How to Get Rid of Annoying IFs Forever

How to Get Rid of Annoying IFs Forever

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

10 Predictions About the Future of Finance

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps