-
Are you going to do something different in the 'nested if' example if, in fact, txtPackage.Text isn't empty but contains something other than "abc"?
If you aren't, I'd ask why are you checking for string.empty at all?
You could just write:
if (txtPackage.Text == "abc")
{
//
}
and be done with it.
Totally depends upon what you want to do in the end.
-
You really need to define what you mean by "better".
My style is to use one if and an AND if, like in your example, I'm testing the same thing for two different values.
If the two tests are conceptually different, I'll probably nest them
if (!user_option.work_offline) {
if (no_current_connection) {
start_connection()
}
}
-
+1 to itsmatt
On the original question, I personally avoid nested ifs wherever possible, otherwise I'd end up with lots of arrow code.
There are, however, exceptions to this mini-rule. If there is going to be different behaviour for each of the conditional outcomes, then nested ifs may be an answer. You need to carefully consider the impact of nesting so you don't write difficult to read (and therefore maintain) code.
-
I wasn't going to chime in, but seeing that some answers here seem to be about "I like my code to look like this"... I feel that I should say something :)
"Better" means the code will execute faster, or it's more readable / extendable. You would want to nest your if's in the case that you would possibly have multiple checks that all have a common requirement.
Example:
if (myThingy != null)
{
if (myThingy.Text = "Hello") ...
if (myThingy.SomethingElse = 123) ...
}
EDIT: It also needs to be said that nesting your IF's requires more CPU cycles (and is therefore "slower") than a single IF. On top of that, the order of your conditions can greatly increase performance.
Exapmle again:
if (somethingQuick() && somethingThatTakesASecondToCalculate()) ...
is a LOT faster (of course) than
if (somethingThatTakesASecondToCalculate() && somethingQuick()) ...
Because if the first part of the IF fails, the second part won't even be executed, thus saving time.
-
I prefer using conditional AND/OR operators when needed, instead of nested ifs. Looks less messy and makes for less lines of code.
if (thisIsTrue) {
if (thisIsTrueToo) doStuff();
}
is essentally same as:
if (thisIsTrue && thisIsTrueToo) doStuff();
if thisIsTrue is false, the second condition is not evaluated. Works also for || for conditional OR.
-
I think it depends on how you want it to flow, if you are only executing on true, true (or any other singularity) then one if statement is all you need.
-
I feel that it is better to avoid nested ifs.
Sometimes, I even duplicate simple tests to avoid a nesting level.
Example (python):
# I prefer:
if a and b:
foo()
elif a and not b:
bar()
elif not a and b:
foobar()
elif not a and not b:
baz()
# Instead of:
if a:
if b:
foo()
else:
bar()
else:
if b:
foobar()
else:
baz()
Sometimes it is more natural to have an else-clause as the last part. In those cases, I typically assert the conditions of the else clause. Example:
if a and b:
foo()
elif a and not b:
bar()
elif not a and b:
foobar()
elif not a and not b:
baz()
else:
assert not a and not b
baz()
-
It depends on what exactly you want to achieve. It's a logical question rather than a programming query. If you have a dependent condition i.e. If the first is TRUE and then test the second condition; if second TRUE then do something , if FALSE do something, in this case you need to use a nested if. But you need the state of both the conditions to do something then you can go with the operators.
-
In my opinion, you should use the style that makes the most sense for what you're testing for. If the two are closely coupled, you could test for both on the same line without a loss of clarity. Particularly easy when the program permits "if x == (1 OR 2)" constructions.
On the other hand, if the two tests are disjointed, I'd prefer to separate them to make the logic more explicit.
