I found some related to my question, but not exactly fit.
In algorithm using if statement, as I know we can omit else statement when we have no execution for false against condition.
For example, if A > B then (statement)
end
However, I want to know if we can omit only "else" like this.
If A > B then (statement), (else omitting point) (statement2)
Is it ok to use like this?
if(condition)
statement1;
else
statement2;
if(condition)
statement1;
//omit else
statement2;
Is this what you want to do? If yes, then no, you can't do that.
In the first case, statement2 is executed only if the condition provided in if is not satisfied. In the second case however, statement2 is executed in all scenarios i.e if the condition is true or false. hence you shouldn't do this unless you want it to behave that way.
Related
I saw this kind of code in vb6.
Private Enum enmMain
STEP_INIT = 1
STEP_RUN = 2
STEP_SLEEP = 3
STEP_SUSPEND = 4
STEP_ERROR = 5
End Enum
Private mStep As enmMain
Select Case mStep
Case Is <= enmMain.STEP_RUN
'Do something
Case enmMain.STEP_RUN To enmMain.STEP_ERROR
'Do something
I don't understand this:
Case enmMain.STEP_RUN To enmMain.STEP_ERROR
If it goes into that case when it meets this condition:
the latest value is STEP_RUN
current value is STEP_ERROR
How does it work?
I am posting on mobile can't write clean.
It means that the case statement will be satisfied by all values of mStep that are between 2 and 5, inclusive.
So there is an imprecision in code. Because the value STEP_RUN appears in an inclusive test twice (see the <= operator). Which behaviour is intended for STEP_RUN, the first or the second? You need to figure it out by understanding the program's logic.
Well, let's read the manual:
If testexpression matches any Case expressionlist expression, the statements following that Case clause are executed up to the next Case clause, or, for the last clause, up to End Select. Control then passes to the statement following End Select. If testexpression matches an expressionlist expression in more than one Case clause, only the statements following the first match are executed.
Select Case will run the first block that matches, and the criteria you can use to match are much more flexible than those allowed in many other languages. Case Is <= enmMain.STEP_RUN Will run for any value of mStep that is less than or equal to 2, and Case enmMain.STEP_RUN To enmMain.STEP_ERROR would run for any value between 2 and 5 inclusive.
Now it seems like somebody didn't quite understand what that meant, though, or at least wrote it in a confusing way, because for a value of 2 only the first Case would run, since as the section I quoted says only the first match is executed.
So the end result is that first 'Do something will run on values of 2 or less, and the second 'Do something will run on values of 3, 4, or 5.
I have the following code:
package main
import (
"fmt"
)
func main() {
switch {
case 1 == 1:
fmt.Println("1 == 1")
fallthrough
case 2 == 1:
fmt.Println("2 == 1")
}
}
Which prints both lines on the go playground - see example here. I would have expected the fallthrough statement to include evaluation of the next case statement, but this seems not to be the case.
Of course, I can always use a bunch of if statements, so this is not a real impediment, but I am curious what the intention here is, since this seems to me to be a non-obvious result.
Anyone care to explain? For example: in this code, how can I get the 1st and 3rd cases to execute?
Switch is not a bunch of ifs. It's more akin to if {} else if {} construct, but with a couple of twists - namely break and fallthrough. It's not possible to make switch execute first and third cases - a switch does not check each condition, it finds first match and executes it. That's all.
It's primary purpose is to walk through a list of possible values and execute a different code for each value. In fact, in C (where switch statement came from) switch expression can only be of integral type and case values can only be constants that switch expression will be compared too. It's only relatively recently, languages started adding support for strings, boolean expressions etc in switch cases.
As to fallthrough logic it also comes from C. There is no fallthrough operator in C. In C execution falls through into next case (without checking case values) unless break operator encountered. The reason for this design is that sometimes you need to do something special and then do same steps as in another case. So, this design merely allows that. Unfortunately, it's rather rarely useful, so falling through by default was causing more trouble when programmer forgotten to put a break statement in, then actually helping when truly omitted that break intentionally. So, many modern languages change this logic to never fall through by default and to require explicit fallthrough statement if falling through is actually required.
Unfortunately, it's a it hard to come up with a non contrived example of fallthrough being useful that would be short enough to fit into an answer. As I said it's relatively rare. But sometimes you need to write code similar to this:
if x == a || x == b {
if x == a {
// do action a
}
// do action ab
} else if x == c {
// do action c
} else if x == d {
// do action d
}
In fact, I needed code of similar structure quite recently in one of my projects. So, I used switch statement instead. And it looked like this:
switch x {
case a: // do action a
fallthrough
case b: // do action ab
case c: // do action c
case d: // do action d
}
And your switch from the question is functionally equivalent to this:
if 1 == 1 || 2 == 1 {
if 1 == 1 {
fmt.Println("1 == 1")
}
fmt.Println("2 == 1")
}
Presumably, Go's fallthrough behavior is modeled after C, which always worked like this. In C, switch statements are just shorthands for chains of conditional gotos, so your particular example would be compiled as if it was written like:
# Pseudocode
if 1 == 1 goto alpha
if 2 == 1 goto beta
alpha:
fmt.Println("1 == 1")
beta:
fmt.Println("2 == 1")
As you can see, once execution enters the alpha case, it would just keep flowing down, ignoring the beta label (since labels by themselves don't really do anything). The conditional checks have already happened and won't happen again.
Hence, the non-intuitive nature of fallthrough switch statements is simply because switch statements are thinly veiled goto statements.
From the language spec:
A "fallthrough" statement transfers control to the first statement of the next case clause in an expression "switch" statement. It may be used only as the final non-empty statement in such a clause.
That seems to perfectly describe your observed behavior.
I'm using a for loop, and inside the for loop are two if-statements that are both being checked for each iteration of the for loop. My issue is that once one of the if-statements = True, then I want the True if-statement to stop being checked, and only check the second if-statement. Or vice versa.
print("Guess the numbers it is! Your goal is to guess a two digit number from 00-99. The two digits may be the same.")
numGuessesN = int(input("How many guesses would you like? (2, 3, or 4) "))
for numGuessesN in range (firstGuess, numGuessesN + 1) :
print("Guess number", numGuessesN)
userGuessN = int(input("What is your guess? "))
if (userGuessN == randomNum1) :
print("You've guessed the first number!")
break
else :
print("The first number is not", userGuessN)
if (userGuessN == randomNum2) :
print("You've guessed the second number!")
break
else :
print("The second number is not", userGuessN)
I know the breaks in the if-statements will completely exit the for loop, and that's not what I want. But somehow I need the for loop to "break" for only each individual statement if it turns out the statement is true, and keep checking the remaining statement until it's true, or the loop runs out of iterations.
Thanks guys! I'm new to all of this, so I'm sorry if I'm not really clear haha.
either you use nested if-statements, or (in case you have a lot, so you would have a lot of repeated code) you set a variable
first_wrong=False
if bla:
pass
else:
first_wrong=True
if bla2 and not first_wrong:
pass
if bla3 and not first_wrong:
pass
I have a rather specific question.
Say I am at the end of a function, and am determining whether to return true or false.
I would like to do this using an if/else statement, and have two options: (examples are in pseudocode)
1) Check if worked first:
if(resultVar != error){
return true;
}else{
return false;
}
2) Check if it failed first:
if(resultVar == error){
return false;
}else{
return true;
}
My question is simple: Which case is better (faster? cleaner?)?
I am really looking at the if/else itself, disregarding that the example is returning (but thanks for the answers)
The function is more likely to want to return true than false.
I realize that these two cases do the exact same thing, but are just 'reversed' in the order of which they do things. I would like to know if either one has any advantage over the other, whether one is ever so slightly faster, or follows a convention more closely, etc.
I also realize that this is extremely nitpicky, I just didn't know if there is any difference, and which would be best (if it matters).
Clarifications:
A comparison needs to be done to return a boolean. The fact that of what the examples are returning is less relevant than how the comparison happens.
This is by far the cleanest:
return resultvar != error;
The only difference in both examples may be the implementation of the operator. A != operator inverses the operation result. So it adds an overhead, but very small one. The == is a straight comparison.
But depending on what you plan to do on the If/else, if there is simply assigning a value to a variable, then the conditional ternary operator (?) is faster. For complex multi value decisions, a switch/case is more flexible, but slower.
This will be faster in your case:
return (resultVar == error) ? false : true;
This will depend entirely on the language and the compiler. There is no specific answer. In C for instance, both of these would be encoded rather like:
return (resultVar!=error);
by any decent compiler.
Put true first, because it potentially eleiminates a JUMP command in assembly. However, the difference is negligible, since it's an else, rather than an else if. There may /technically be a difference/, but you will see no performance difference in this case.
I occasionally do something like....
IF very-likely-condition THEN
NULL;
ELSE
<<code to deal with the unlikely condition>>
END IF;
Which gives a PLW-06002 unreachable code warning from the PL/SQL compiler on the NULL line atfer the IF.
Now whilst I can clearly ignore the warning and/or refactor the IF statement to be a NOT, I think it reads better this way.
So does anybody know is there is another way of inserting an empty statement so that I don't get the compiler warning?
EDIT:
I'm not saying I do this often... in fact I'd do it very rarely. But occasionally I do think it reads better this way.
EDIT 2:
Plus there are other scenarios where it might be valid to do this (such as ignoring a specific error in an EXCEPTION block). I only used the IF as a simple example to illustrate the point.
To Recursive And Weblog :
the following statements are NOT equivalent:
IF :x = 0 THEN
NULL;
ELSE
do_something;
END IF;
and
IF NOT :x = 0 THEN
do_something;
END IF;
If :x IS NULL the do_something procedure will be called in the first case only. This is because the expression NULL = 0 is neither TRUE nor FALSE in Oracle, it is "unknown".
The correct way to re-write the first statement would be:
IF :x != 0 OR :x IS NULL THEN
do_something;
END IF;
I can see why in some cases we could write things as the OP.
Looks like this is by design. See http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/controlstructures.htm#i5421
Example 4-23 Using NULL as a Placeholder When Creating a Subprogram
CREATE PROCEDURE ... AS
BEGIN
NULL; -- use NULL as placeholder, raises "unreachable code" if warnings enabled
END;
/
Why do you have an empty statement? That's a code smell. It's generally accepted that is it not easier to read with an empty if block.
Change your if condition to the opposite of what it currently is:
IF NOT very-likely-condition THEN
<<code to deal with the unlikely condition>>
END IF;
If you need to do something when the condition is true, you can always add that block back in. Empty blocks separate the condition from the block that's executed when the condition is true. It also looks like you used to have code in the if section, then removed it but were too lazy to rewrite the if condition to remove the empty statement.
Subjectively, if I were reading your code and saw the empty if block, I'd think you didn't know what you were doing.