Refactoring nested conditionals in PHP

[@CarloJS]

Thanks Dave, this video helped me alot to understand how to reformat messy nested ifs

[@aurielklasovsky1435]

Impress your boss with this one simple trick!

[@palomarAI]

Arrow-shaped animation was helpful and the improved readability is striking to a relative novice such as myself. In fact I read a book on PHP several years ago and the examples if I recall did show a lot of these big arrow-shaped decisions so I guess that's quite common in legacy code.

[@dave-hollingworth]

I'm really glad you liked the animation - it's the first time I've tried it using new video editing software :-)
And yes you're right, this is very common in legacy code (including some of my own I'm sure!)

[@jarencefeliciano]

Is is still work wen I don't want to return a value. Just an array? I'm doing dat way currently but still executing parts of da code dat souldn't be executed.

[@dave-hollingworth]

The return statement immediately exits from the function and returns a value, so if you want to do something else, you'll have to take this into account if you don't want the code after it to be executed.

[@hallexcosta]

which text editor do you use?

[@dave-hollingworth]

In the videos I use Atom (atom.io/), but when coding I actually use Vim ;-)

[@hallexcosta]

@@dave-hollingworth Do you know where I can learn to install Vim on my machine?

[@TroyNiemeier]

Hi Dave.
I do take some issues with these examples. And maybe I shouldn't because they're only examples... So I apologize up front for the pickiness.
Refactoring nested conditionals like you're demonstrating is not generally a good idea. Sure, it allows your code to be horizontally flatter, but why do you want your code to handle all of the negative, undesirable, exceptional cases before it gets onto the whole point of the function/script?! Why are we saving the best for last? To me, it makes so much more sense to directly code for the intended/ideal case and to Hell with how many nested, indented code blocks it takes. Most of the time I'm interested in knowing what qualifies something as valid, not what qualifies it as invalid (like your examples switch to), which requires the reader to invert the logic to comprehend.
$errorText = null;
function fileIsValid($file)
{
if($file['error'] === UPLOAD_ERR_OK)
{
if($file['size'] < 1000000)
{
if($file['type'] === 'image/png')
{
return true;
}
else
{
$errorText = 'invalid file type';
}
}
else
{
$errorText = 'file is too large';
}
}
else
{
$errorText = 'an error occurred';
}

return false;
}
if(fileIsValid($_FILES['file']))
{
move_uploaded_file($_FILES['file']['tmp_name'], '/uploads/file.png');
}
else
{
throw new Exception($errorText);
}

[@dave-hollingworth]

Hi Troy,
no need to apologise, I appreciate the discussion! Yes, they're just examples, so they are a bit contrived. In coming up with them, I wanted something real world, as opposed to pseudo-code like "if ($condition1)" and so on.
I see your point, but the problem with many levels of nested if statements is that it's difficult to follow the program flow. At first glance you can't quickly see which else block goes with which if statement. And adding another one is problematic, as it's very easy to get the curly braces in the wrong place, and associate an else block with the wrong if. The idea with refactoring to remove this is it's simpler to see what the flow does. Yes, you're right that the "negative" parts of the code occur first, before the actual thing you want to do happens, but that's a necessary side-effect. This is why they're known as "guard clauses", as they guard the actual thing you want to do by checking for errors / validating it first.
There's a longer explanation of the problem and why refactoring like this can address it here: blog.codinghorror.com/flattening-arrow-code/
and a slightly different example (and much shorter explanation) here: refactoring.guru/replace-nested-conditional-with-guard-clauses
I see code like that all the time, with several levels of nested conditionals, and it's really hard to debug, especially if the author hasn't used proper code indentation.
However, it's up to you of course, whatever style you prefer!