Hi all,
Maybe I'm just having a mental block here, but I can't see how to make an "else" belong to the outer "if" of a nested "if"...
if (outer test)
{
if (inner test)
{
//stuff
}
else // I want this to be alternate to "outer test" not "inner test"
{
//stuff
}
}
Am I missing a trick here guys?
EDIT.... I'm thinking I should put both tests in the first (and thus only) if with &&
if (outer test && inner test)
{
//stuff
}
else
{
//stuff
}
Like this:
if (outer test){
if (inner test){
//stuff
}
}else{
}
You where missing the }{ on the else, without it the else becomes part of the inner test. I put the brackets on the same line as the code it refers to, it makes things far clearer.
You will need to repeat the inner test if needed in the else part. If its not needed and outer test is not used exclusively you can simply write:
if (outer test && inner test){
//Stuff
}else{
}
JimboZA:
Hi all,
Maybe I'm just having a mental block here, but I can't see how to make an "else" belong to the outer "if" of a nested "if"...
if (outer test)
{
if (inner test)
{
//stuff
}
else // I want this to be alternate to "outer test" not "inner test"
{
//stuff
}
}
Am I missing a trick here guys?
Perhaps using the autoformat tool would help?
Keeping braces { } on their own lines makes it far easier to match them.
How many times does anyone need to play Where's Waldo over a misplaced character in crowded code to learn that?
if (outer test)
{
if (inner test)
{
//stuff
} // end if (inner test)
} // end if (outer test)
else // else not (outer test)
{
//stuff
}
What is it that you teach?
Thanks both of you, basically the same answer, ie I had one closing brace in the wrong place and that attached the else to the wrong if.
As you say pYro I would have had to redo the inner test if required. I don't need it in this case since its result is irrelevant if the outer test fails, and that's what made me edit my question and add the && approach as an alternate which works in this case.
If you place the cursor in the source code window immediately behind a code block brace (e.g., if, for, while, etc.), the editor "boxes" the matching brace. That feature of the editor makes it pretty easy to see what belongs to what.
econjack:
If you place the cursor in the source code window immediately behind a code block brace (e.g., if, for, while, etc.), the editor "boxes" the matching brace. That feature of the editor makes it pretty easy to see what belongs to what.
Yep I know, thanks. It wasn't that my braces were unbalanced, it was that I hadn't actually twigged to the fact of putting the closing brace above the else to associate the else with the outer if not the inner one.
That's why you'll see people comment closing braces. There was some trouble or a desire to avoid trouble.
At least with the comment you can see what was intended.
I will write a statement that uses braces and right after the opening brace I make the next line with the closer and finish that level, put in the else and braces if I need before going back and filling in details.
if ()
{
}
else if ()
{
}
else
{
}
and then fill it in.
If you write a pseudocode version of the sketch with each line as a comment then write the code between the pseudocode lines it can really help staying on track. Just remember to change those comments when the code won't be doing as you first planned. Misleading comments are worse than no comments at all.
Autoformat will not complete unless parens and braces are balanced and some other checks are good. For that alone it is good to use autoformat early and often.
good suggestion, as a guy who used to make a lot of nested errors, i even go to the extra step of adding the empty line or some pseudo code in between:
{
if (something)
{
if
{
// Test for stateFlag
}
}
else
{
}
}
the empty line, with standard indents, is a nice visual clue to me that I need to fill that in.