Salathe said it right when he said don't indent too deeply. I always avoid that whenever I can. I dislike even having an
if within an
if; sometimes it's unavoidable. Nor do I like adding
else statements, again, sometimes it cannot be helped!
For instance, to give a simple example, instead of adding an
else for a
return statement, I would aim to
return that within the
if statement, and knowing that if, as below, it did evaluate to
true then it wouldn't reach the second
return, and thus saving us an
else.
php Code:
function doThisAndThat($bTrueOrFalse)
{
if ($bTrueOrFalse)
{
return 'It is true';
}
/* If the above is true we can be sure it's NOT true here. */
return 'It is false';
}
In addendum to this, I also like to make good use of
continue in loops. For example:
php Code:
foreach ($aMember as $pMember)
{
if ($pMember->isNotLoggedIn())
{
continue;
}
/* Again, if the above evaluates to true then it wouldn't get here. */
$aLoggedIn[] = $pMember;
}
That also saves us an
else, and makes our code, at least in my eyes, much easier to read.
I don't know if I can explain this awfully well, but I like to exclude all the items we
don't want in the subsequent code first, instead of deciding what we need to include, and then placing an
else at the bottom to handle the exclusions.
This is the way I
wouldn't do it
(I wish to save the good way for the end so your mind retains it!)
php Code:
if ($bTrueOrFalse)
{
/* The bad way: Handle the stuff we want to include and process.
This is the main chunk of our code and so likely to contain
many loops and conditionals. */
}
else
{
/* Handle the exclusions. Likely to contain many else statements. */
}
Last but not least, the way
I would do it, as in the first two examples, is like so:
php Code:
if ($bTrueOrFalse)
{
/* This stuff is not required by the below code
as it has an undesirable attribute/property. */
continue; /* Therefore we exclude it and continue. */
}
/* Continue with the stuff that we really do need to include,
now that we've filtered out all the bad stuff. Instead of handling
what we need first and then adding an else at the bottom to handle
the exclusions. */
In simple form it could be shown as the following:
(I found this UML diagram creator yesterday via Reddit. Seems quite useful! Seems it can also be used for lovely flow charts.)
The underlining assumption behind this way of working is that the chunk of code required for processing exclusions will be smaller than the code for processing inclusions. Inclusions being the items we want to work with. This saves us having huge chunks of code for processing inclusions, and then having lots of isolated
else statements at the bottom handling exclusions.
Hopefully this more real-life example will crystallise this in your mind:
php Code:
if ($pMember->isInactive())
{
/* Member is not active, so we don't want to deal
with this. It becomes an excluded item. Perhaps
we want to also send an email to inactive members
to remind them to activate their accounts. */
$pMember->sendReminder();
return;
}
if ($pMember->isAdministrator())
{
/* Member is an administrator, and we don't wish to
work with administrators in this scenario, again,
exclude this item. */
return;
}
/* We now have a list of members who are active and are not
administrators. Perfect! Let's begin work on processing that now.
These are what I call "inclusions", whereas the above two process
the "exclusions" -- items we don't require in this process. */
/* This is likely to be the epicentre of the code... */