[^SmileY]

public FMVoiceSetClientListening(Recv,Sender,bool:Listen)
{
	if(Recv != Sender)
	{
		if(is_user_connected(Recv) && is_user_connected(Sender))
		{
			if(get_user_team(Recv) == get_user_team(Sender))
			{
				engfunc(EngFunc_SetClientListening,Recv,Sender,true);
				return FMRES_SUPERCEDE;
			}
		}
	}
	
	return FMRES_IGNORED;
}

Versus

public FMVoiceSetClientListening(Recv,Sender,bool:Listen)
{
	if(Recv != Sender && is_user_connected(Recv) && is_user_connected(Sender) && get_user_team(Recv) == get_user_team(Sender))
	{
		engfunc(EngFunc_SetClientListening,Recv,Sender,true);
		return FMRES_SUPERCEDE;
	}
	
	return FMRES_IGNORED;
}

I made this code to ask, if first is better than second example.
Because if first check is false, the plugin will not call other (sub) checks

At second example same if is calling both functions at same time.
Someone more skilled than me can sane this doubt?

Thanks again

[NiHiLaNTh]

If you have multiple AND's chained, than if the first expression is false, the compiler won't check the others.

[maqi]

Exactly, as far as i know, if you are chaining AND's, it goes left to right, as soon as one is false, it won't check further. For OR's it won't check the others as soon as one is true.

Following that logic the thing you should look out for, is how likely an expression is to be true, place the less likely ones up front But anyway i think that the performance gain from this is minimal, but good practice.

[^SmileY]

Originally Posted by NiHiLaNTh If you have multiple AND's chained, than if the first expression is false, the compiler won't check the others.

Is execution time not at compile time no?

@maqi
I doubt that in execution time the plugin will not continue checking before first check fail since it in same line.
Also i guess performance is relative that what is calling the function (How many times) / frame or second for example.

Lets see other users to have sure

[maqi]

That is exactly what im saying, i could be wrong, but i was always thought like this, I just wanted to pass it on.

[^SmileY]

I tried to check pawn documentation, but this not explain nothing

I will use FIRST example to have sure

[klippy]

They will probably compile to same bytecode (or with little differences that won't matter to performance). What Maqi said is true and that phenomenon is called "short-circuit evaluation".

[^SmileY]

Originally Posted by KliPPy They will probably compile to same bytecode (or with little differences that won't matter to performance). What Maqi said is true and that phenomenon is called "short-circuit evaluation".

Anyway first example is more readable than first, short-circuit evaluation is not mentioned in pawn anyway thanks

[naz7]

Originally Posted by ^SmileY Anyway first example is more readable than first, short-circuit evaluation is not mentioned in pawn anyway thanks

In my opinion the first is more readable as long as it doesn't make the function too big. I like functions that can fit in the screen without having to scroll, either horizontally or vertically. Generally I would go with the second option, which as KliPPy stated probably compiles to the same bytecode. If the condition gets too wide you can break the line, and have 2 conditional parts in a line and other 2 below. Anyways I think the most important thing is that your code stays consistent, if you go with that code style keep it along the whole script.

[CrazY.]

I like more with return values, but that's doesn't matter if you do not do wrong.

public FMVoiceSetClientListening(Recv,Sender,bool:Listen)
{
    if (Recv == Sender)
        return FMRES_IGNORED;

    if (!is_user_connected(Recv) || !is_user_connected(Sender))
        return FMRES_IGNORED;

    if (get_user_team(Recv) != get_user_team(Sender))
        return FMRES_IGNORED;
    
    engfunc(EngFunc_SetClientListening,Recv,Sender,true);
    return FMRES_SUPERCEDE;
}