If..Then..Else worth.

[Crisp_N_Dry]

This may sound like a odd/stupid/obvious question but it's something that has bothered me for a while and it regards If Then Else statements. Are they a viable programming method? I realise there are certain situations where an If Then Else statement is of course necessary but it seems that on larger projects I feel I'm using them too often. I usually try and find a more elegant way of doing things but it isn't always possible. Anyone wanna put my mind at ease or am I really doing things wrong? How much is too much when it comes to this most basic of programming functionalities?

[WILL]

I think this is quite a common issue with many programmers. I myself am found starting at a blob of if statements at times wondering how to simplify it.

If you find that you are having a whole series of if statements all to check 1 value then a case..of..else statement would be better use. Sometimes you just have to if-away, but when possible try to reduce the amount of conditional statements, as they take up valuable processing power too.

[Sly]

With modern CPUs that use branch prediction to prefetch code into the cache based on what it thinks the outcome of the if statement will be, it is generally better to put the most common case in the 'if' section and the least common case in the 'else' section.

[cronodragon]

With modern CPUs that use branch prediction to prefetch code into the cache based on what it thinks the outcome of the if statement will be, it is generally better to put the most common case in the 'if' section and the least common case in the 'else' section.

Wow, I always declared my 'if' blocks that way, and until now I didn't know it made a difference.

For functions, at the beginning I usually assign Result with the pessimist value, and at the end I assign the success value. In the middle I use Exit or Break for failure conditions.

Another trick is, while developing I don't use 'if' or 'try' to check anything. Instead I let every possible error arise, and I correct the code to make the errors dissapear, disabling the conditions that create them. When I feel the solution is ready, I go line by line placing security checks where something could go wrong. That reduces the amount of unnecessary 'if' blocks and unexpected errors.

[marmin]

i like if.. then :D what could be faster than that? it's very direct and clear. I think it's much more important to optimize a procedure , how all statements are aligned, and place exits, continues, and breaks where needed so that code doesn't need to be readed when not needed. assembly lanugage is full of if's and breaks, jumps, and exits, i like it.

[LP]

I realise there are certain situations where an If Then Else statement is of course necessary but it seems that on larger projects I feel I'm using them too often.

If you use IF...THEN too often and feel it's becoming an obsession, worry no more since WHILE...DO is here to help you!



procedure I_am_annoyed_by_this();
begin
if (Cost > 100) then ShowMessage('The cost is too high!')
else ShowMessage('The cost is too low!');
end;

procedure A_happy_replacement();
begin
while (Cost > 100) do
begin
ShowMessage('The cost is too high!');
Break;
end;
while &#40;Cost <= 100&#41; do
begin
ShowMessage&#40;'The cost is too low!'&#41;;
Break;
end;
end;

[User137]

If you use IF...THEN too often and feel it's becoming an obsession, worry no more since WHILE...DO is here to help you!
That is a joke, right? lol

While..DO makes a similar IF compare in addition to its loop behaviour...

[Paulius]

If you have a blob of confusing ifs then you?¢_Tre original program structure is probably broken after countless fixes and its time to restructure it into clearly defined objects and methods.

[Nitrogen]

Another one that I like to use is the in operator, like so:



if MyInt in &#91;1,3,5,6&#93; then
...


And another thing to remember is to make use of boolean short circuting.
Where you use boolean algebra, the compiler can stop evaluating the if statement early.

I'm not sure, but I think the second form would be more efficient:



//1.

If A = true then
If B = true then
if C = true then
DoSomething;

//2.

If &#40;A and B and C&#41; then
DoSomething;



So if A is false, the compiler knows not to even bother checking B and C in the second form.

[User137]

Style 2 is normally faster, but style 1 is faster if B or C are slow functions or other calculations.

Also sometimes you need multiple if with objects:

This may result in access violation:
if (obj<>nil) and (obj.name='test') then

But this is error free:
if obj<>nil then
if obj.name='test' then

This on the other hand may be slower but works too:
if assigned(obj) then
if obj.name='test' then

[LP]

Style 2 is normally faster, but style 1 is faster if B or C are slow functions or other calculations.
You are wrong. In fact, they both will generate the same code if short-circuit Boolean expression evaluation is used (equals to "{$B-}").


This may result in access violation:
if (obj<>nil) and (obj.name='test') then
Again, you are wrong if "{$B-}" is used (by default). In fact, if you are accessing an object (e.g. "if (obj.position.x = 25) then") and suspect that it can be nil, you can add "obj <> nil" comparison before the initial condition (e.g. "if (obj <> nil)and(obj.position.x = 25) then") to be sure.

Of course, if you use complete Boolean expression evaluation (equals to "{$B+}"), your points are valid. I've never seen any Pascal code using complete Boolean evaluation though.

[User137]

Thanks... that immediately showed new way to optimize if clauses (place most frequent break conditions first).

More about B- here:
http://www.delphibasics.co.uk/RTL.asp?Name=$B