What is the purpose of an 'if (0)' block in if-else block?
up vote
62
down vote
favorite
My question is about the line I have mentioned in the subject and which I can see in many places inside the production code.
The overall code looks like this:
if (0) {
// Empty braces
} else if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
The other branches are irrelevant to my question. I'm wondering what the meaning of putting if (0)
here is. The braces are empty, so I don't think that it is supposed to comment some block of code. Does it force the compiler to make some optimization or are its intentions different?
I have tried to search for this explicit case here on SO and on the internet, but with no success. There're similar questions about JavaScript, but not C. There's another question, What happens when a zero is assigned in an `if` condition?, but it discusses zero assignment to a variable, not the 'if (0)' usage itself.
c if-statement
New contributor
add a comment |
up vote
62
down vote
favorite
My question is about the line I have mentioned in the subject and which I can see in many places inside the production code.
The overall code looks like this:
if (0) {
// Empty braces
} else if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
The other branches are irrelevant to my question. I'm wondering what the meaning of putting if (0)
here is. The braces are empty, so I don't think that it is supposed to comment some block of code. Does it force the compiler to make some optimization or are its intentions different?
I have tried to search for this explicit case here on SO and on the internet, but with no success. There're similar questions about JavaScript, but not C. There's another question, What happens when a zero is assigned in an `if` condition?, but it discusses zero assignment to a variable, not the 'if (0)' usage itself.
c if-statement
New contributor
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
2
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago
add a comment |
up vote
62
down vote
favorite
up vote
62
down vote
favorite
My question is about the line I have mentioned in the subject and which I can see in many places inside the production code.
The overall code looks like this:
if (0) {
// Empty braces
} else if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
The other branches are irrelevant to my question. I'm wondering what the meaning of putting if (0)
here is. The braces are empty, so I don't think that it is supposed to comment some block of code. Does it force the compiler to make some optimization or are its intentions different?
I have tried to search for this explicit case here on SO and on the internet, but with no success. There're similar questions about JavaScript, but not C. There's another question, What happens when a zero is assigned in an `if` condition?, but it discusses zero assignment to a variable, not the 'if (0)' usage itself.
c if-statement
New contributor
My question is about the line I have mentioned in the subject and which I can see in many places inside the production code.
The overall code looks like this:
if (0) {
// Empty braces
} else if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
The other branches are irrelevant to my question. I'm wondering what the meaning of putting if (0)
here is. The braces are empty, so I don't think that it is supposed to comment some block of code. Does it force the compiler to make some optimization or are its intentions different?
I have tried to search for this explicit case here on SO and on the internet, but with no success. There're similar questions about JavaScript, but not C. There's another question, What happens when a zero is assigned in an `if` condition?, but it discusses zero assignment to a variable, not the 'if (0)' usage itself.
c if-statement
c if-statement
New contributor
New contributor
edited 2 days ago
Boann
36.5k1286119
36.5k1286119
New contributor
asked 2 days ago
Zzaponka
42247
42247
New contributor
New contributor
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
2
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
2
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
2
2
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago
add a comment |
12 Answers
12
active
oldest
votes
up vote
36
down vote
accepted
I sometimes use this for symmetry so I can move the other else if{
freely around with my editor without having to mind the first if
.
Semantically the
if (0) {
// Empty braces
} else
part doesn't do anything and you can count on optimizers to delete it.
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
@user694733: You could argue that the commonif else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)
– M Oehm
2 days ago
54
I don't thinkif (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" thatif
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.
– P.P.
2 days ago
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
Even using this pattern, I don't know if you can "moveelse if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use onlyif
, and perform early return, extracting the logic chain to a separate function if necessary.
– John Wu
yesterday
|
show 12 more comments
up vote
46
down vote
This can be useful if there are #if
statements, ala
if (0)
{
// Empty block
}
#if TEST1_ENABLED
else if (test1())
{
action1();
}
#endif
#if TEST2_ENABLED
else if (test2())
{
action2();
}
#endif
etc.
In this case, any (and all) of the tests can be #if
'ed out, and the code will compile correctly. Almost all compilers will remove the if (0) {}
part.
A simple autogenerator could generate code like this, as it is slightly easier to code - it doesn't have to consider the first enabled block separately.
3
In many cases, anif
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seenif(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.
– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split theelse if
line into two and put the preprocessor guard in between.
– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove theif (0)
branch and reformat the rest such thatelse
is on its own line, surrounded by a guard along the lines of#if TEST1_ENABLED && TEST2_ENABLED
.
– Konrad Rudolph
20 hours ago
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
|
show 2 more comments
up vote
22
down vote
I've seen a similar pattern used in generated code. For example, in SQL, I've seen libraries emit the following where
clause.
where 1 = 1
This presumably makes it easier to just add on other criteria, because all additional criteria can be prepended with and
instead of an additional check to see if it is the first criteria or not.
2
The1=1
is also "useful" because you can always add thewhere
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating thewhere
clause.
– Bakuriu
yesterday
2
In addition, most databases will automatically "remove" the1=1
from theWHERE
, so it doesn't have an impact on performance.
– Nic Hartley
yesterday
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
|
show 2 more comments
up vote
21
down vote
As written, the if (0) {}
clause compiles out to nothing.
I suspect the function of the clause at the top of this ladder is to provide an easy place to temporarily disable all the other functionality at once (for debugging or comparison purposes) by changing the 0
to a 1
or true
.
add a comment |
up vote
9
down vote
Not sure of any optimizations, but my two cents :
This happened because of some code modification, where one primary condition was removed, (the function call in initial if
block, let's say), but the devs/ maintainers
- were lazy to restructure the
if-else
block - did not want to go down on the branch coverage count
so instead of removing the associated if
block, they simply changed the condition to if(0)
and moved on.
2
Isn'tif(0)
decrease branch coverage too?
– David Szalai
yesterday
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
add a comment |
up vote
7
down vote
It's code rot.
At some point that "if" did something useful, the situation changed, maybe the variable being evaluated was removed.
The person who was fixing/changing the system did as little as possible to affect the logic of the system so he just made sure the code would recompile. So he leaves an "if(0)" because that's quick and easy and he's not totally sure that's what he wants to do. He gets the system working and he doesn't go back to fix it completely.
Then the next developer comes along and thinks that was done deliberately and only comments out that part of the code (since it's not being evaluated anyway), then the next time the code is touched those comments are removed.
add a comment |
up vote
5
down vote
I think it's just bad code. Writing a quick example in Compiler Explorer, we see that in both gcc and clang no code is generated for the if (0)
block, even with optimizations completely disabled:
https://godbolt.org/z/PETIks
Playing around with removing the if (0)
causes no changes to the generated code, so I conclude that this is not an optimization.
It's possible that there used to be something in the top if
block which was later removed. In short, it looks like removing it would cause the exact same code to be generated, so feel free to do that.
add a comment |
up vote
5
down vote
One possibility not yet mentioned: the if (0) {
line could be providing a convenient spot for a breakpoint.
Debugging is often done on non-optimised code so the always-false test will be present and able to have breakpoint set on it. When compiled for production, the line of code would be optimised out. The seemingly useless line gives functionality for development and testing builds without impacting release builds.
There are other good suggestions above as well; the only way to really know what the purpose is, is to track down the author and ask. Your source code control system might help with that. (Look for blame
-type functionality.)
add a comment |
up vote
2
down vote
As it's been said, the zero is evaluated to false, and the branch will likely be optimized out by the compiler.
I've also seen this before in code where a new feature was added and a kill-switch was needed (if something goes wrong with the feature you can just turn it off), and some time later when the kill-switch was removed the programmer didn't also remove the branch, e.g.
if (feature_a_active()) {
use_feature_a();
} else if (some_fn()) {
...
became
if (0) {
// empty
} else if (some_fn()) {
...
New contributor
add a comment |
up vote
1
down vote
I've seen non reachable code blocks in pre-expanded JavaScript that have been generated using a templating language.
For instance, the code you are reading could have been pasted from a server that pre-evaluated the first condition that at that time relied on a variable only available on server side.
if ( ${requestIsNotHttps} ){ ... }else if( ...
which once pre-compiled hences :
if ( 0 ){ ... }else if ( ...
hope this helps you relativise the potential low keyboard activity of the pro-recycling coders era for which i manifest enthusiasm !
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
add a comment |
up vote
0
down vote
I have seen this a few times, I think the most likely reason is it was evaluating something in an older/different version/branch of the code, or possibly for debugging, and changing it to if(0)
is a somewhat lazy way of removing whatever was there.
add a comment |
up vote
-5
down vote
if (0)
will always evaluate to false. The code in the question is functionally equivalent to
if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
Possibly, this occurred because of code being deleted in the first if
block and there was a possibility of it being reinserted, so the if
part was kept.
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it withif (0)
as shown by OP. There may be some previous code that was there and later removed withif(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
add a comment |
12 Answers
12
active
oldest
votes
12 Answers
12
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
36
down vote
accepted
I sometimes use this for symmetry so I can move the other else if{
freely around with my editor without having to mind the first if
.
Semantically the
if (0) {
// Empty braces
} else
part doesn't do anything and you can count on optimizers to delete it.
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
@user694733: You could argue that the commonif else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)
– M Oehm
2 days ago
54
I don't thinkif (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" thatif
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.
– P.P.
2 days ago
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
Even using this pattern, I don't know if you can "moveelse if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use onlyif
, and perform early return, extracting the logic chain to a separate function if necessary.
– John Wu
yesterday
|
show 12 more comments
up vote
36
down vote
accepted
I sometimes use this for symmetry so I can move the other else if{
freely around with my editor without having to mind the first if
.
Semantically the
if (0) {
// Empty braces
} else
part doesn't do anything and you can count on optimizers to delete it.
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
@user694733: You could argue that the commonif else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)
– M Oehm
2 days ago
54
I don't thinkif (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" thatif
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.
– P.P.
2 days ago
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
Even using this pattern, I don't know if you can "moveelse if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use onlyif
, and perform early return, extracting the logic chain to a separate function if necessary.
– John Wu
yesterday
|
show 12 more comments
up vote
36
down vote
accepted
up vote
36
down vote
accepted
I sometimes use this for symmetry so I can move the other else if{
freely around with my editor without having to mind the first if
.
Semantically the
if (0) {
// Empty braces
} else
part doesn't do anything and you can count on optimizers to delete it.
I sometimes use this for symmetry so I can move the other else if{
freely around with my editor without having to mind the first if
.
Semantically the
if (0) {
// Empty braces
} else
part doesn't do anything and you can count on optimizers to delete it.
edited yesterday
answered 2 days ago
PSkocik
30.6k54368
30.6k54368
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
@user694733: You could argue that the commonif else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)
– M Oehm
2 days ago
54
I don't thinkif (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" thatif
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.
– P.P.
2 days ago
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
Even using this pattern, I don't know if you can "moveelse if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use onlyif
, and perform early return, extracting the logic chain to a separate function if necessary.
– John Wu
yesterday
|
show 12 more comments
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
@user694733: You could argue that the commonif else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)
– M Oehm
2 days ago
54
I don't thinkif (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" thatif
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.
– P.P.
2 days ago
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
Even using this pattern, I don't know if you can "moveelse if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use onlyif
, and perform early return, extracting the logic chain to a separate function if necessary.
– John Wu
yesterday
168
168
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
Personal opinion: While this may be the reason code why it is written as it is, I think it's a bad justification. Code is read more often than it's written, and this unnecessary code just increases parsing overhead for the reader.
– user694733
2 days ago
10
10
@user694733: You could argue that the common
if else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)– M Oehm
2 days ago
@user694733: You could argue that the common
if else
prefix to all significant code paths lines the conditions up nicely and makes scaning them easier. (That's subjective, though, and would depend a lot of what's really inside the conditions and code blocks.)– M Oehm
2 days ago
54
54
I don't think
if (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" that if
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.– P.P.
2 days ago
I don't think
if (0) {..}
introduces any parsability/readability problem. It should be obvious to anyone who knows a bit of C. That's not an issue. The problem is the follow-up question after reading it: "What the hell is it for then?" Unless it's for debugging/temporary purposes (i.e., the intention is to "enable" that if
block later), I'd advocate removing altogether. Basically "reading" such code would likely cause an unnecessary "pause" for the reader for no good reason. And that's a good enough a reason to remove it.– P.P.
2 days ago
46
46
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
Seems like it definitely detracts from readability. It was so bad it sent that programmer to SO to ask what it was for. Not a good sign.
– Vectorjohn
yesterday
15
15
Even using this pattern, I don't know if you can "move
else if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use only if
, and perform early return, extracting the logic chain to a separate function if necessary.– John Wu
yesterday
Even using this pattern, I don't know if you can "move
else if
around the editor without worry" because the conditions may not be mutually exclusive, in which case order matters. Personally I would use only if
, and perform early return, extracting the logic chain to a separate function if necessary.– John Wu
yesterday
|
show 12 more comments
up vote
46
down vote
This can be useful if there are #if
statements, ala
if (0)
{
// Empty block
}
#if TEST1_ENABLED
else if (test1())
{
action1();
}
#endif
#if TEST2_ENABLED
else if (test2())
{
action2();
}
#endif
etc.
In this case, any (and all) of the tests can be #if
'ed out, and the code will compile correctly. Almost all compilers will remove the if (0) {}
part.
A simple autogenerator could generate code like this, as it is slightly easier to code - it doesn't have to consider the first enabled block separately.
3
In many cases, anif
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seenif(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.
– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split theelse if
line into two and put the preprocessor guard in between.
– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove theif (0)
branch and reformat the rest such thatelse
is on its own line, surrounded by a guard along the lines of#if TEST1_ENABLED && TEST2_ENABLED
.
– Konrad Rudolph
20 hours ago
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
|
show 2 more comments
up vote
46
down vote
This can be useful if there are #if
statements, ala
if (0)
{
// Empty block
}
#if TEST1_ENABLED
else if (test1())
{
action1();
}
#endif
#if TEST2_ENABLED
else if (test2())
{
action2();
}
#endif
etc.
In this case, any (and all) of the tests can be #if
'ed out, and the code will compile correctly. Almost all compilers will remove the if (0) {}
part.
A simple autogenerator could generate code like this, as it is slightly easier to code - it doesn't have to consider the first enabled block separately.
3
In many cases, anif
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seenif(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.
– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split theelse if
line into two and put the preprocessor guard in between.
– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove theif (0)
branch and reformat the rest such thatelse
is on its own line, surrounded by a guard along the lines of#if TEST1_ENABLED && TEST2_ENABLED
.
– Konrad Rudolph
20 hours ago
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
|
show 2 more comments
up vote
46
down vote
up vote
46
down vote
This can be useful if there are #if
statements, ala
if (0)
{
// Empty block
}
#if TEST1_ENABLED
else if (test1())
{
action1();
}
#endif
#if TEST2_ENABLED
else if (test2())
{
action2();
}
#endif
etc.
In this case, any (and all) of the tests can be #if
'ed out, and the code will compile correctly. Almost all compilers will remove the if (0) {}
part.
A simple autogenerator could generate code like this, as it is slightly easier to code - it doesn't have to consider the first enabled block separately.
This can be useful if there are #if
statements, ala
if (0)
{
// Empty block
}
#if TEST1_ENABLED
else if (test1())
{
action1();
}
#endif
#if TEST2_ENABLED
else if (test2())
{
action2();
}
#endif
etc.
In this case, any (and all) of the tests can be #if
'ed out, and the code will compile correctly. Almost all compilers will remove the if (0) {}
part.
A simple autogenerator could generate code like this, as it is slightly easier to code - it doesn't have to consider the first enabled block separately.
answered yesterday
CSM
49249
49249
3
In many cases, anif
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seenif(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.
– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split theelse if
line into two and put the preprocessor guard in between.
– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove theif (0)
branch and reformat the rest such thatelse
is on its own line, surrounded by a guard along the lines of#if TEST1_ENABLED && TEST2_ENABLED
.
– Konrad Rudolph
20 hours ago
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
|
show 2 more comments
3
In many cases, anif
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seenif(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.
– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split theelse if
line into two and put the preprocessor guard in between.
– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove theif (0)
branch and reformat the rest such thatelse
is on its own line, surrounded by a guard along the lines of#if TEST1_ENABLED && TEST2_ENABLED
.
– Konrad Rudolph
20 hours ago
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
3
3
In many cases, an
if
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seen if(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.– supercat
yesterday
In many cases, an
if
/else if
chain isn't used so much as a decision tree, but rather as an "act upon first matching condition" construct, where the condition that happens to have the highest-priority isn't particularly "special". While I'd not seen if(0)
used as a way to allow all real branches to have consistent syntax, I like the consistent syntax it facilitates.– supercat
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split the
else if
line into two and put the preprocessor guard in between.– Konrad Rudolph
yesterday
It’s not even useful in this case because you can achieve the same effect without: just split the
else if
line into two and put the preprocessor guard in between.– Konrad Rudolph
yesterday
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@KonradRudolph I'm not following; how would you write it?
– JiK
21 hours ago
@JiK I’d remove the
if (0)
branch and reformat the rest such that else
is on its own line, surrounded by a guard along the lines of #if TEST1_ENABLED && TEST2_ENABLED
.– Konrad Rudolph
20 hours ago
@JiK I’d remove the
if (0)
branch and reformat the rest such that else
is on its own line, surrounded by a guard along the lines of #if TEST1_ENABLED && TEST2_ENABLED
.– Konrad Rudolph
20 hours ago
3
3
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
@KonradRudolph that's fine if you want to double the number of guards and triple the number of guard conditions mentioned, I suppose.
– hobbs
16 hours ago
|
show 2 more comments
up vote
22
down vote
I've seen a similar pattern used in generated code. For example, in SQL, I've seen libraries emit the following where
clause.
where 1 = 1
This presumably makes it easier to just add on other criteria, because all additional criteria can be prepended with and
instead of an additional check to see if it is the first criteria or not.
2
The1=1
is also "useful" because you can always add thewhere
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating thewhere
clause.
– Bakuriu
yesterday
2
In addition, most databases will automatically "remove" the1=1
from theWHERE
, so it doesn't have an impact on performance.
– Nic Hartley
yesterday
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
|
show 2 more comments
up vote
22
down vote
I've seen a similar pattern used in generated code. For example, in SQL, I've seen libraries emit the following where
clause.
where 1 = 1
This presumably makes it easier to just add on other criteria, because all additional criteria can be prepended with and
instead of an additional check to see if it is the first criteria or not.
2
The1=1
is also "useful" because you can always add thewhere
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating thewhere
clause.
– Bakuriu
yesterday
2
In addition, most databases will automatically "remove" the1=1
from theWHERE
, so it doesn't have an impact on performance.
– Nic Hartley
yesterday
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
|
show 2 more comments
up vote
22
down vote
up vote
22
down vote
I've seen a similar pattern used in generated code. For example, in SQL, I've seen libraries emit the following where
clause.
where 1 = 1
This presumably makes it easier to just add on other criteria, because all additional criteria can be prepended with and
instead of an additional check to see if it is the first criteria or not.
I've seen a similar pattern used in generated code. For example, in SQL, I've seen libraries emit the following where
clause.
where 1 = 1
This presumably makes it easier to just add on other criteria, because all additional criteria can be prepended with and
instead of an additional check to see if it is the first criteria or not.
answered yesterday
seth flowers
7,31721735
7,31721735
2
The1=1
is also "useful" because you can always add thewhere
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating thewhere
clause.
– Bakuriu
yesterday
2
In addition, most databases will automatically "remove" the1=1
from theWHERE
, so it doesn't have an impact on performance.
– Nic Hartley
yesterday
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
|
show 2 more comments
2
The1=1
is also "useful" because you can always add thewhere
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating thewhere
clause.
– Bakuriu
yesterday
2
In addition, most databases will automatically "remove" the1=1
from theWHERE
, so it doesn't have an impact on performance.
– Nic Hartley
yesterday
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
2
2
The
1=1
is also "useful" because you can always add the where
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating the where
clause.– Bakuriu
yesterday
The
1=1
is also "useful" because you can always add the where
in front, unconditionally. Otherwise you'd have to check if it's empty, and if so avoid generating the where
clause.– Bakuriu
yesterday
2
2
In addition, most databases will automatically "remove" the
1=1
from the WHERE
, so it doesn't have an impact on performance.– Nic Hartley
yesterday
In addition, most databases will automatically "remove" the
1=1
from the WHERE
, so it doesn't have an impact on performance.– Nic Hartley
yesterday
4
4
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is acceptable in a library that automatically generates SQL queries that are most likely never seen even by the DevOps team. It's not "acceptable" in high-level code that has to be written and read multiple times.
– phagio
yesterday
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
This is really handy approach when generating some kind of dynamic SQL with unknown number of final conditions.
– Skipper
2 hours ago
1
1
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
@freakish indeed I wrote the opposite: poorly readable syntax is acceptable in generated code since it will most likely never be read, not in high-level functional code that is maintained by developers.
– phagio
1 hour ago
|
show 2 more comments
up vote
21
down vote
As written, the if (0) {}
clause compiles out to nothing.
I suspect the function of the clause at the top of this ladder is to provide an easy place to temporarily disable all the other functionality at once (for debugging or comparison purposes) by changing the 0
to a 1
or true
.
add a comment |
up vote
21
down vote
As written, the if (0) {}
clause compiles out to nothing.
I suspect the function of the clause at the top of this ladder is to provide an easy place to temporarily disable all the other functionality at once (for debugging or comparison purposes) by changing the 0
to a 1
or true
.
add a comment |
up vote
21
down vote
up vote
21
down vote
As written, the if (0) {}
clause compiles out to nothing.
I suspect the function of the clause at the top of this ladder is to provide an easy place to temporarily disable all the other functionality at once (for debugging or comparison purposes) by changing the 0
to a 1
or true
.
As written, the if (0) {}
clause compiles out to nothing.
I suspect the function of the clause at the top of this ladder is to provide an easy place to temporarily disable all the other functionality at once (for debugging or comparison purposes) by changing the 0
to a 1
or true
.
answered yesterday
Russell Borogove
13.1k2938
13.1k2938
add a comment |
add a comment |
up vote
9
down vote
Not sure of any optimizations, but my two cents :
This happened because of some code modification, where one primary condition was removed, (the function call in initial if
block, let's say), but the devs/ maintainers
- were lazy to restructure the
if-else
block - did not want to go down on the branch coverage count
so instead of removing the associated if
block, they simply changed the condition to if(0)
and moved on.
2
Isn'tif(0)
decrease branch coverage too?
– David Szalai
yesterday
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
add a comment |
up vote
9
down vote
Not sure of any optimizations, but my two cents :
This happened because of some code modification, where one primary condition was removed, (the function call in initial if
block, let's say), but the devs/ maintainers
- were lazy to restructure the
if-else
block - did not want to go down on the branch coverage count
so instead of removing the associated if
block, they simply changed the condition to if(0)
and moved on.
2
Isn'tif(0)
decrease branch coverage too?
– David Szalai
yesterday
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
add a comment |
up vote
9
down vote
up vote
9
down vote
Not sure of any optimizations, but my two cents :
This happened because of some code modification, where one primary condition was removed, (the function call in initial if
block, let's say), but the devs/ maintainers
- were lazy to restructure the
if-else
block - did not want to go down on the branch coverage count
so instead of removing the associated if
block, they simply changed the condition to if(0)
and moved on.
Not sure of any optimizations, but my two cents :
This happened because of some code modification, where one primary condition was removed, (the function call in initial if
block, let's say), but the devs/ maintainers
- were lazy to restructure the
if-else
block - did not want to go down on the branch coverage count
so instead of removing the associated if
block, they simply changed the condition to if(0)
and moved on.
answered 2 days ago
Sourav Ghosh
107k14129185
107k14129185
2
Isn'tif(0)
decrease branch coverage too?
– David Szalai
yesterday
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
add a comment |
2
Isn'tif(0)
decrease branch coverage too?
– David Szalai
yesterday
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
2
2
Isn't
if(0)
decrease branch coverage too?– David Szalai
yesterday
Isn't
if(0)
decrease branch coverage too?– David Szalai
yesterday
1
1
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
@DavidSzalai Not completely - at most it will decrease by 1 (from previous 2) - but one hit will still be required for coverage, to the best of my knowledge.
– Sourav Ghosh
yesterday
add a comment |
up vote
7
down vote
It's code rot.
At some point that "if" did something useful, the situation changed, maybe the variable being evaluated was removed.
The person who was fixing/changing the system did as little as possible to affect the logic of the system so he just made sure the code would recompile. So he leaves an "if(0)" because that's quick and easy and he's not totally sure that's what he wants to do. He gets the system working and he doesn't go back to fix it completely.
Then the next developer comes along and thinks that was done deliberately and only comments out that part of the code (since it's not being evaluated anyway), then the next time the code is touched those comments are removed.
add a comment |
up vote
7
down vote
It's code rot.
At some point that "if" did something useful, the situation changed, maybe the variable being evaluated was removed.
The person who was fixing/changing the system did as little as possible to affect the logic of the system so he just made sure the code would recompile. So he leaves an "if(0)" because that's quick and easy and he's not totally sure that's what he wants to do. He gets the system working and he doesn't go back to fix it completely.
Then the next developer comes along and thinks that was done deliberately and only comments out that part of the code (since it's not being evaluated anyway), then the next time the code is touched those comments are removed.
add a comment |
up vote
7
down vote
up vote
7
down vote
It's code rot.
At some point that "if" did something useful, the situation changed, maybe the variable being evaluated was removed.
The person who was fixing/changing the system did as little as possible to affect the logic of the system so he just made sure the code would recompile. So he leaves an "if(0)" because that's quick and easy and he's not totally sure that's what he wants to do. He gets the system working and he doesn't go back to fix it completely.
Then the next developer comes along and thinks that was done deliberately and only comments out that part of the code (since it's not being evaluated anyway), then the next time the code is touched those comments are removed.
It's code rot.
At some point that "if" did something useful, the situation changed, maybe the variable being evaluated was removed.
The person who was fixing/changing the system did as little as possible to affect the logic of the system so he just made sure the code would recompile. So he leaves an "if(0)" because that's quick and easy and he's not totally sure that's what he wants to do. He gets the system working and he doesn't go back to fix it completely.
Then the next developer comes along and thinks that was done deliberately and only comments out that part of the code (since it's not being evaluated anyway), then the next time the code is touched those comments are removed.
answered 23 hours ago
Dark Matter
1955
1955
add a comment |
add a comment |
up vote
5
down vote
I think it's just bad code. Writing a quick example in Compiler Explorer, we see that in both gcc and clang no code is generated for the if (0)
block, even with optimizations completely disabled:
https://godbolt.org/z/PETIks
Playing around with removing the if (0)
causes no changes to the generated code, so I conclude that this is not an optimization.
It's possible that there used to be something in the top if
block which was later removed. In short, it looks like removing it would cause the exact same code to be generated, so feel free to do that.
add a comment |
up vote
5
down vote
I think it's just bad code. Writing a quick example in Compiler Explorer, we see that in both gcc and clang no code is generated for the if (0)
block, even with optimizations completely disabled:
https://godbolt.org/z/PETIks
Playing around with removing the if (0)
causes no changes to the generated code, so I conclude that this is not an optimization.
It's possible that there used to be something in the top if
block which was later removed. In short, it looks like removing it would cause the exact same code to be generated, so feel free to do that.
add a comment |
up vote
5
down vote
up vote
5
down vote
I think it's just bad code. Writing a quick example in Compiler Explorer, we see that in both gcc and clang no code is generated for the if (0)
block, even with optimizations completely disabled:
https://godbolt.org/z/PETIks
Playing around with removing the if (0)
causes no changes to the generated code, so I conclude that this is not an optimization.
It's possible that there used to be something in the top if
block which was later removed. In short, it looks like removing it would cause the exact same code to be generated, so feel free to do that.
I think it's just bad code. Writing a quick example in Compiler Explorer, we see that in both gcc and clang no code is generated for the if (0)
block, even with optimizations completely disabled:
https://godbolt.org/z/PETIks
Playing around with removing the if (0)
causes no changes to the generated code, so I conclude that this is not an optimization.
It's possible that there used to be something in the top if
block which was later removed. In short, it looks like removing it would cause the exact same code to be generated, so feel free to do that.
answered 2 days ago
cha0site
7,80322644
7,80322644
add a comment |
add a comment |
up vote
5
down vote
One possibility not yet mentioned: the if (0) {
line could be providing a convenient spot for a breakpoint.
Debugging is often done on non-optimised code so the always-false test will be present and able to have breakpoint set on it. When compiled for production, the line of code would be optimised out. The seemingly useless line gives functionality for development and testing builds without impacting release builds.
There are other good suggestions above as well; the only way to really know what the purpose is, is to track down the author and ask. Your source code control system might help with that. (Look for blame
-type functionality.)
add a comment |
up vote
5
down vote
One possibility not yet mentioned: the if (0) {
line could be providing a convenient spot for a breakpoint.
Debugging is often done on non-optimised code so the always-false test will be present and able to have breakpoint set on it. When compiled for production, the line of code would be optimised out. The seemingly useless line gives functionality for development and testing builds without impacting release builds.
There are other good suggestions above as well; the only way to really know what the purpose is, is to track down the author and ask. Your source code control system might help with that. (Look for blame
-type functionality.)
add a comment |
up vote
5
down vote
up vote
5
down vote
One possibility not yet mentioned: the if (0) {
line could be providing a convenient spot for a breakpoint.
Debugging is often done on non-optimised code so the always-false test will be present and able to have breakpoint set on it. When compiled for production, the line of code would be optimised out. The seemingly useless line gives functionality for development and testing builds without impacting release builds.
There are other good suggestions above as well; the only way to really know what the purpose is, is to track down the author and ask. Your source code control system might help with that. (Look for blame
-type functionality.)
One possibility not yet mentioned: the if (0) {
line could be providing a convenient spot for a breakpoint.
Debugging is often done on non-optimised code so the always-false test will be present and able to have breakpoint set on it. When compiled for production, the line of code would be optimised out. The seemingly useless line gives functionality for development and testing builds without impacting release builds.
There are other good suggestions above as well; the only way to really know what the purpose is, is to track down the author and ask. Your source code control system might help with that. (Look for blame
-type functionality.)
answered 19 hours ago
studog
1298
1298
add a comment |
add a comment |
up vote
2
down vote
As it's been said, the zero is evaluated to false, and the branch will likely be optimized out by the compiler.
I've also seen this before in code where a new feature was added and a kill-switch was needed (if something goes wrong with the feature you can just turn it off), and some time later when the kill-switch was removed the programmer didn't also remove the branch, e.g.
if (feature_a_active()) {
use_feature_a();
} else if (some_fn()) {
...
became
if (0) {
// empty
} else if (some_fn()) {
...
New contributor
add a comment |
up vote
2
down vote
As it's been said, the zero is evaluated to false, and the branch will likely be optimized out by the compiler.
I've also seen this before in code where a new feature was added and a kill-switch was needed (if something goes wrong with the feature you can just turn it off), and some time later when the kill-switch was removed the programmer didn't also remove the branch, e.g.
if (feature_a_active()) {
use_feature_a();
} else if (some_fn()) {
...
became
if (0) {
// empty
} else if (some_fn()) {
...
New contributor
add a comment |
up vote
2
down vote
up vote
2
down vote
As it's been said, the zero is evaluated to false, and the branch will likely be optimized out by the compiler.
I've also seen this before in code where a new feature was added and a kill-switch was needed (if something goes wrong with the feature you can just turn it off), and some time later when the kill-switch was removed the programmer didn't also remove the branch, e.g.
if (feature_a_active()) {
use_feature_a();
} else if (some_fn()) {
...
became
if (0) {
// empty
} else if (some_fn()) {
...
New contributor
As it's been said, the zero is evaluated to false, and the branch will likely be optimized out by the compiler.
I've also seen this before in code where a new feature was added and a kill-switch was needed (if something goes wrong with the feature you can just turn it off), and some time later when the kill-switch was removed the programmer didn't also remove the branch, e.g.
if (feature_a_active()) {
use_feature_a();
} else if (some_fn()) {
...
became
if (0) {
// empty
} else if (some_fn()) {
...
New contributor
edited 2 days ago
New contributor
answered 2 days ago
sergiopm
764
764
New contributor
New contributor
add a comment |
add a comment |
up vote
1
down vote
I've seen non reachable code blocks in pre-expanded JavaScript that have been generated using a templating language.
For instance, the code you are reading could have been pasted from a server that pre-evaluated the first condition that at that time relied on a variable only available on server side.
if ( ${requestIsNotHttps} ){ ... }else if( ...
which once pre-compiled hences :
if ( 0 ){ ... }else if ( ...
hope this helps you relativise the potential low keyboard activity of the pro-recycling coders era for which i manifest enthusiasm !
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
add a comment |
up vote
1
down vote
I've seen non reachable code blocks in pre-expanded JavaScript that have been generated using a templating language.
For instance, the code you are reading could have been pasted from a server that pre-evaluated the first condition that at that time relied on a variable only available on server side.
if ( ${requestIsNotHttps} ){ ... }else if( ...
which once pre-compiled hences :
if ( 0 ){ ... }else if ( ...
hope this helps you relativise the potential low keyboard activity of the pro-recycling coders era for which i manifest enthusiasm !
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
add a comment |
up vote
1
down vote
up vote
1
down vote
I've seen non reachable code blocks in pre-expanded JavaScript that have been generated using a templating language.
For instance, the code you are reading could have been pasted from a server that pre-evaluated the first condition that at that time relied on a variable only available on server side.
if ( ${requestIsNotHttps} ){ ... }else if( ...
which once pre-compiled hences :
if ( 0 ){ ... }else if ( ...
hope this helps you relativise the potential low keyboard activity of the pro-recycling coders era for which i manifest enthusiasm !
I've seen non reachable code blocks in pre-expanded JavaScript that have been generated using a templating language.
For instance, the code you are reading could have been pasted from a server that pre-evaluated the first condition that at that time relied on a variable only available on server side.
if ( ${requestIsNotHttps} ){ ... }else if( ...
which once pre-compiled hences :
if ( 0 ){ ... }else if ( ...
hope this helps you relativise the potential low keyboard activity of the pro-recycling coders era for which i manifest enthusiasm !
answered yesterday
simonarame
1005
1005
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
add a comment |
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
1
1
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
I agree, in the age of ubiquitous automation we should rely on autogenerated code more, as it allows us to spend more time on actual things. But for now, my exact point of interest is how this everything is architectured under the hood.
– Zzaponka
yesterday
add a comment |
up vote
0
down vote
I have seen this a few times, I think the most likely reason is it was evaluating something in an older/different version/branch of the code, or possibly for debugging, and changing it to if(0)
is a somewhat lazy way of removing whatever was there.
add a comment |
up vote
0
down vote
I have seen this a few times, I think the most likely reason is it was evaluating something in an older/different version/branch of the code, or possibly for debugging, and changing it to if(0)
is a somewhat lazy way of removing whatever was there.
add a comment |
up vote
0
down vote
up vote
0
down vote
I have seen this a few times, I think the most likely reason is it was evaluating something in an older/different version/branch of the code, or possibly for debugging, and changing it to if(0)
is a somewhat lazy way of removing whatever was there.
I have seen this a few times, I think the most likely reason is it was evaluating something in an older/different version/branch of the code, or possibly for debugging, and changing it to if(0)
is a somewhat lazy way of removing whatever was there.
answered yesterday
John U
1,64511529
1,64511529
add a comment |
add a comment |
up vote
-5
down vote
if (0)
will always evaluate to false. The code in the question is functionally equivalent to
if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
Possibly, this occurred because of code being deleted in the first if
block and there was a possibility of it being reinserted, so the if
part was kept.
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it withif (0)
as shown by OP. There may be some previous code that was there and later removed withif(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
add a comment |
up vote
-5
down vote
if (0)
will always evaluate to false. The code in the question is functionally equivalent to
if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
Possibly, this occurred because of code being deleted in the first if
block and there was a possibility of it being reinserted, so the if
part was kept.
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it withif (0)
as shown by OP. There may be some previous code that was there and later removed withif(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
add a comment |
up vote
-5
down vote
up vote
-5
down vote
if (0)
will always evaluate to false. The code in the question is functionally equivalent to
if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
Possibly, this occurred because of code being deleted in the first if
block and there was a possibility of it being reinserted, so the if
part was kept.
if (0)
will always evaluate to false. The code in the question is functionally equivalent to
if (some_fn_call()) {
// actual code
} else if (some_other_fn_call()) {
// another actual code
...
} else {
// default case
}
Possibly, this occurred because of code being deleted in the first if
block and there was a possibility of it being reinserted, so the if
part was kept.
edited 2 days ago
answered 2 days ago
Rishikesh Raje
5,1241825
5,1241825
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it withif (0)
as shown by OP. There may be some previous code that was there and later removed withif(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
add a comment |
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it withif (0)
as shown by OP. There may be some previous code that was there and later removed withif(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
14
14
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
The question does not seek definition of the code shown, question is why is it the way it is?
– Sourav Ghosh
2 days ago
I do not see any reason to code it with
if (0)
as shown by OP. There may be some previous code that was there and later removed with if(0)
– Rishikesh Raje
2 days ago
I do not see any reason to code it with
if (0)
as shown by OP. There may be some previous code that was there and later removed with if(0)
– Rishikesh Raje
2 days ago
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
Usually, these constructs are used to keep other conditions in similar syntax. It's an aesthetic choice.
– Rushabh Mehta
yesterday
2
2
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
Actually that's what i do while debugging. Instead of deleting a possibly problematic if clause, I just skip it by adding ( false && 'original boolean check'), just to make sure that if is not causing mischief. This particular answer is suggesting just that. It is a valid answer, dear down-voters please reconsider your position.
– brett
yesterday
add a comment |
Zzaponka is a new contributor. Be nice, and check out our Code of Conduct.
Zzaponka is a new contributor. Be nice, and check out our Code of Conduct.
Zzaponka is a new contributor. Be nice, and check out our Code of Conduct.
Zzaponka is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53298646%2fwhat-is-the-purpose-of-an-if-0-block-in-if-else-block%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
13 hours ago
2
That statement seems irrelevant. Generate assembly code with and without that statement and you will see what is going under the hood.
– haccks
5 hours ago
It's possible this is an automatically generated code.
– freakish
2 hours ago