Affirming the Negative and Doing Nothing

[Lucid_Stew]

In the sections around this point in the course we are doing a lot of checks for negative conditions and then returning nothing as a result. I am curious of the benefit of this approach as opposed to affirming the logical positive opposite with an if and leaving it at that.

[QueueButton]

You can write the code however you feel is logical. There’s always going to be someone who will criticize your code.

Edit: So here’s an example of Epic doing it… and they are big in gaming, programming, very well known, and long time established.

3 - Implementing Projectiles

if(!RootComponent)
{
RootComponent = CreateDefaultSubobject<USceneComponent>(TEXT("ProjectileSceneComponent"));
}
if(!CollisionComponent)
{
...

Who’s to argue with using a negative if? Why? There’s no point. It works. They have a product used to bring in billions in cash.

The important point is that the code does what you want it to do and is hopefully bug free other than the unforeseen problems that everyone runs into because no human can think of every possibility.

[Lucid_Stew]

I think you misunderstood my post. I’m not criticizing using NOT statements in a conditional. I am asking what the benefit is of confirming that a collection of negatives is valid and then returning nothing, which would logically be followed by an else representing all other logical possibilities. This as opposed to starting with the positives, and then ignoring the rest, since they do nothing.

[QueueButton]

Indeed, I can’t grasp your meaning. If you can find the final code. It looks like toon tanks ue4 project if I understand their tags correctly: Source · master · GameDev.tv / Unreal Course / 04 Toon Tanks · GitLab

Not sure if it falls under validation but it sounds like according to you that their code basically has no value at all which would only make sense if its not finished.

Pretty much the only thing I’m seeing that could be what you might be talking about is stuff like:

	if(!MyOwner)
	{
		return;
	}
	// If the other actor ISN'T self OR Owner AND exists, then apply damage.
	if (...

Stuff like that can be coded any way you want. That probably falls under personal preference.

But its a quick check before running the rest of the function and returns if something isn’t good before continuing. Many people do that. I do that. Epic does it too…

Components and Collision

    // Make sure that everything is still valid, and that we are allowed to move.
    if (!PawnOwner || !UpdatedComponent || ShouldSkipUpdate(DeltaTime))
    {
        return;
    }

    // Get (and then clear) the movement vector that we set in ACollidingPawn::Tick
    FVector ...

Again, you can definitely not do that if you don’t want to. You’re free to do it whatever way you want.

I often do it to bring the code left more instead of wrapping eg an if inside an if or other reasons. But you could use a function for each boolean if you wanted or an entirely different class. In this case, you could eliminate the else block indentation.

However I usually do these without the curly brackets and keep it all on one line if its not too long or unless multiple lines of code are needed. That’s just how I like to do it. My preference.

Maybe that answers what you’re asking?

[DanM]

To avoid large nested code.

if (Condition1)
{
    // Some code
    if (Condition2)
    {
        // Some more code
        if  (Condition3)
        {
            // We're good to go. Remaining logic of the function goes here.
        }
    }
}

That would be more easily read if using guards.

if (!Condition1)
{
    return;
}

// Some code

if (!Condition2)
{
    return;
}

// Some more code

if  (Condition3)
{
   // We're good to go. Remaining logic of the function goes here.
}
 

[Lucid_Stew]

Makes sense, Dan. Thanks for the response!

[Lucid_Stew]

I ran into this situation in the Creating a Health Component part of this section that I thought was a good use of this to avoid an extra condition before Health is calculated.