5

I would like to know if leaving an empty if statement for certain situations as:

else if(typeof console === 'undefined'){}

Just to have the code bypass the rest of the function It is an accepted and safe way to work or there are other recommendation practices for these cases?. Thank you.

Santiago Rebella
  • 2,399
  • 2
  • 22
  • 29

7 Answers7

7

It's fine and safe to leave if branches empty, the only thing I would add is a comment:

else if(typeof console === 'undefined')
{
    //explanation why nothing has to go here
}

Without seeing the rest of the code I'm unsure how you're using this to "bypass the rest of the function", there may be a better way to do this.

martinwnet
  • 571
  • 2
  • 4
  • 10
4

From what information you've provided me, I can glean that the answer is "no". It will work, but it's bad style. If you would like to bypass the rest of the function, why not return; or put most of the logic in the if statement that pertains to it so that there is no bypassing at all?

Vinay
  • 6,204
  • 6
  • 38
  • 55
2

Same as Pioul's answer, but I'd add that imo checking existence in javascript looks much tidier with the !! (notnot) operator.

if(!!console){
    // your code
}
// else if(!console){}
// you don't need that second part
Rob Hardy
  • 1,821
  • 15
  • 15
  • 1
    I ve been recommended to use allways === to avoid truthy cases. Also in a google talks video about javascript the good parts recommends this – Santiago Rebella Oct 10 '12 at 10:04
2

I just had a case in which I chose to use an empty if-statement (professional context). I must agree though, there definitely is a technically cleaner solution. Still, since in a professional context time is important too, I chose to use the empty if-statement in my case, so I wanted to share my train of thought with you.

In my case I'm patching existing code with a variable that is used to skip already existing nested if-statements. The main function keeps running before and after the statement.

Original Code:

if(bValidateA){
}elseif(bValidateB){
}elseif(bValidateC){
}
// ... code continues with variables set inside the statements.

Now we want to add a global Parameter to not validate anything. What are my options and why do they suck?

Solution A sucks because much work and less easy to read:

if(!bValidateNothing && bValidateA){
}elseif(!bValidateNothing && bValidateB){
}elseif(!bValidateNothing && bValidateC){
}

Solution B sucks because empty if-statement:

if(bValidateNothing){
// empty
}elseif(bValidateA){
}elseif(bValidateB){
}elseif(bValidateC){
}

Solution C sucks because it becomes too nested (in my case there have been some additional ifs in the original code):

if(!bValidateNothing){
    if(bValidateA){
         if(xx){
         }elseif(xy){}
    }elseif(bValidateB){
    }elseif(bValidateC){
    }
}

Solution D, the technically cleanest solution by adding additional functions, sucks because you need to split your code, which needs a lot of time, and may result in new errors.

(no pseudocode)

So, to answer the question "accepted and safe": it works, it's readable, safe and quick. Sometimes that has to be enough, considering the alternatives. If you have the time to avoid using it, I'd probably still recommend that instead.

Funny enough, the time I saved by using this quick way to implement my logic, has now been successfully spent adding my cents to this ten year old already answered question.

1

Just don't write a block for a case you don't want to handle.

If you only want to do something when console exists, then do that:

if(typeof console !== 'undefined'){
    // your code
}
// else if(typeof console === 'undefined'){}
// you don't need that second part

Or maybe I didn't quite get your issue?

aaaaaa
  • 2,588
  • 3
  • 26
  • 31
0

Sometimes it is useful to have debugging information printed out:-

if(typeof console !== 'undefined'){
    console.log("debug info");
}

Then, before releasing the code, simply comment out all the console.log's

//        console.log("debug info");

This can be done with a macro.

It will leave an empty if statement. But this is not a compilation error so that's OK.

Note, that if you're going to comment out the line it is important that braces are used. Otherwise you'd have the next line dependent on the if statement which would be a bleeding shame.

Quentin 2
  • 2,156
  • 1
  • 10
  • 8
0

Using an empty if statement can be a valid and accepted practice in certain situations.

For example, when working with a try-catch block, you may use an empty if statement to handle specific errors without disrupting the rest of the function. Additionally, it can be used for performance optimization by short-circuiting the evaluation of certain conditions.

Make sure that when using an empty if statement, it is properly commented to provide context and explanation for its use.

Example:

try {
// code that may throw an error
} catch (error) {
   if(error instanceof SpecificError) {
    // handle specific error without disrupting the rest of the function
    }
}

Another example:

if(isFirstConditionTrue && isSecondConditionTrue && isThirdConditionTrue) {
// Do something
} else if(isFirstConditionTrue && isSecondConditionTrue) {
// Do nothing, because third condition is false
} else {
// handle other conditions
}

It's always a good practice to add comments explaining the purpose of each empty if statement and why you chose to use it in a certain scenario. It's not generally considered bad style as long as it serves a specific purpose and is well documented.

Lina
  • 1
  • 2