I am using es-lint to clean up the errors in my code. I have come across this error:
Unnecessary 'else' after 'return'. (No-else-return)
} else {
I have always used else statements after a return. Is there something I may be overlooking?
if (cctot <= 3 && cctot > 0) {
alert('Credit under $3.00 not allowed');
return Number.MIN_SAFE_INTEGER; // important to return 0 so we can check for these conditions for validation
} else {
cctot *= -1;
}
return precise(cctot);
What that is basically saying is that the else part of the if statement is unnecessary if there is a return in the if part.
Something like this is what it expects:
if (cctot <= 3 && cctot > 0) {
alert('Credit under $3.00 not allowed');
return Number.MIN_SAFE_INTEGER; // important to return 0 so we can check for these conditions for validation
}
cctot *= -1;
In general, this:
if (condition) {
return something;
} else {
// do another thing
}
return anotherThing;
is similar to:
if (condition) {
return something;
}
// do another thing
return anotherThing;
After the if with a return statement, there is no need for the else part as the code below the if will only run when the condition stated is not fulfilled.
It's a code style preference. You don't need the else and instead can put the else code directly below the if. This is because if the if succeeds, that's the end of the function, so the else code will never be reached anyway.
So this:
if (condition) {
return foo;
} else {
// do bar
}
return baz
is equivalent to this:
if (condition) {
return foo;
}
// do bar
return baz
This style seems to vary in different programming communities. Go developers will nearly always omit the else, while I've seen more JS devs include it.
While I prefer to leave off the else, it is again purely a matter of preference. Don't let it worry you too much. People may get dogmatic about this kind of thing, but it's really not that important.
While the rule correctly points out that the else block is unnecessary, and it is a style preference, I would add additional considerations for readability and most importantly scanability.
For the developer writing this code, and to the machine interpreting it, it may be a style point and that's it. But for the developer who needs to fix a bug, enhance a feature, do a code review, etc. the ability to quickly scan through the code and see the else blocks helps to identify branches of logic.
In a few lines of isolated code it is easy to see the intent, but among hundreds of lines of code having if else blocks can serve as useful identifiers, much like other common visual practices like indentation, line breaks, and naming conventions.
The return statement stops/terminates the current function. It's just saying that there's no need for 'else' since the execution of the function already stopped and if the 'if' condition doesn't succeed, it will still run any code underneath it.
As for best practice, I won't say it's a big of a deal always but with the code in your example, I won't use the else clause because it's simply not needed. I think it's good to understand what's happening under the hood and the reason behind best practices and not just following them.
Related
In javascript I get confused with the nested if's elses
when a JS compiler/engine has this code to interpret
if (cond1)
if (cond2)
statement1
else
statement2
(It is not indented on purpose)
Does it gets interpreted like this?
if (cond1) {
if (cond2) {
statement1
}
}
else {
statement2
}
Or like this?
if (cond1) {
if (cond2) {
statement1
}
else {
statement2
}
}
The question would be: Do the 'else' corresponds to the first or second 'if'?
I would like to know also if this problem of interpretation has some name (like 'operator precedence') (I'm sure it has). I can't find this issue in internet, because I don't know how to search for it by its name.
It might be a little obvious, but I'm going to say it: I ask about javascript because I'm using it right now, but this question could be about almost any procedural language.
it should be the second one in JS. It would throw an error in python and get your nose punched in php as soon as a colleague debugs your code.
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.
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.
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?
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.
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?
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
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.
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.
One of my friends is teaching a programming class with Javascript and one of his assignments was to create a number guessing game. This was his example implementation:
funProgram: for(;;) {
numberGuesser: {
var num = (Math.random() * 100) | 0;
var guess = +prompt("I'm thinking of a number between 0 and 100. Try to guess it.", 0);
var guesses = 1;
guess: for(;;) {
higher: {
lower: {
if(guess === num) break guess;
if(guess > num) break lower;
guess = +prompt("Too low. Try again.", 0);
break higher;
}
guess = +prompt("Too high. Try again.", 0);
}
guesses++;
}
alert("You got it in " + guesses + " guesses! The number is " + num);
}
var again = prompt("Do you want to guess again (y/n)?", "y") === "y";
if(!again) break funProgram;
}
He told me that it's a good practice to label your code and wrap blocks around it so you can easily see what each section is doing. He also said labeled breaks and continues are much easier to read than unlabeled ones because you can know exactly what you are breaking out of. I've never seen any code patterns like this, so I'm not sure if this is true.
I've been using Javascript for a while and there are a few things in here that I've never seen before and some things that I still don't understand. I thought that the break keyword was specifically meant for breaking out of loops. The higher and lower blocks are not loops, but apparently you can still break out of it. How is that possible? It seems odd to me to break out of something that doesn't loop. Can you also break out of functions using the break keyword?
Breaks can in fact have labels (and do so accept them). However, I'm not sure who "He" is, but I would go as far as to say "He" is conveying his ideals of programming, rather than a specific standard. That is to say, there's no need to use labels, it just makes it more legible to that particular person. (And, IMHO, labels are reminiscent of the BASIC/GOTO days which usually results in Spaghetti Code).
Extra Credit: Ask your friend if they used to write in BASIC; I'm betting you'll get a "yes" (along with a lot of bad habits for the duration of the course--that's not to profile, I've just never had a good experience with BASIC/VB programmers following [current] coding patterns))
The break command is commonly used to exit loops, however if the code block is nested within a label, you're establishing yet another block which you can break from. It also gives you a bit more flexibility as to where the break is meant to exit from. For example:
for (;;){ // "for a"
for(;;){ // "for b"
break; // breaks "for b"
}
}
In this instance, break is only meant to exit the nested ("for b") loop. However:
myblock: {
for(;;){
for(;;){
break mybock; // breaks label "myblock"
}
}
}
In this case, break is actually exiting both loops because you're instructing it to quit the label block entirely. This would be almost like having:
function myblock(){
for(;;){
for(;;){
return; // exits function "myblock"
}
}
}
Where return exits the block similar to the way break myblock acts.
By the way, not for nothing, I find this a tad easier to read:
var again = true;
while (again){
var num = (new Date()).getMilliseconds() % 100,
guess = +prompt("I'm thinking of a number between 0 and 100. Try to guess it.", "1"),
guesses = 1;
while (num !== guess){
guesses++;
guess = +prompt((guess < num ? "Too low." : "Too high.") + " Try again.", guess);
}
alert("You got it in " + guesses + " guesses! The number is " + num);
again = prompt("Do you want to guess again? (y/n)", "y") == "y";
}
I can understand the code after a little research on label and break in javascript. However, I personally don't like that style of coding, mainly because the labelled block syntax is too similar to the literal object notation - which I use a lot. And even Mozilla's documentation on labels tell us to avoid them:
Labels are not very commonly used in JavaScript since they make programs harder to read an understand. As much as possible, avoid using labels and, depending on the cases, prefer calling functions or throwing an error.
Regarding your objective questions:
break can be used to exit for loops, while loops and case statements, as well as labelled blocks.
You cannot use break to exit a function, you must use return.
From MDN (bold emphasis mine):
The break statement includes an optional label that allows the program
to break out of a labeled statement. The break statement needs to be
nested within this labelled statement. The labelled statement can be
any block statement; it does not have to be preceded by a loop
statement.
So, yes, labels can be used outside of loops, but, no, you can't use them to return from a function.
Those break statements are being used in the same way that goto is used in older languages. And as Shark pointed out: you can also use them in switch statements, but not in functions.
It's probably confusing to you because he is using the labeled blocks in conjunction with infinite for(;;) loops.
Look at this article here for more information: http://james.padolsey.com/javascript/labelled-blocks-useful/
Why JSLint report in code:
function cos(a) {
var b = 0;
if (a) {
b = 1;
}
else {
b = 2;
}
return b;
}
error:
Problem at line 6 character 5: Expected exactly one space between '}' and 'else'.
This error can be turned off by disabling Tolerate messy white space option of JSLint.
Or in other words -- why syntax:
} else { is better then
...
}
else {
...
Google also uses syntax with } else { form.
But I don't understand why. Google mentioned ''implicit semicolon insertion'', but in context of opening {, not closing one.
Can Javascript insert semicolon after closing } of if block even if next token is else instruction?
Sorry that my question is a bit chaotic -- I tried to think loud.
JSLint is based on Crockford's preferences (which I share in this case).
It's a matter of opinion which is "better".
(Although clearly his opinion is right ;)
It's not a matter of style. It's how ECMAScript works.
For better or for worse, it will automatically insert semicolons at the end of statements where it feels necessary.
JavaScript would interpret this:
function someFunc {
return
{
something: 'My Value'
};
}
As this:
function someFunc {
return;
{
something: 'My Value'
};
}
Which is certainly what you don't want.
If you always put the bracket on the same line as the if and if else statement, you won't run into a problem like this.
As with any coding language, the coding style chosen should be the one that minimizes potential risk the most.
Mozilla Developer Network also promotes same line bracketing: https://developer.mozilla.org/en-US/docs/User:GavinSharp_JS_Style_Guidelines#Brackets
JSLint is being very picky here, just enforcing a style that you might not share.
Try JSHint instead:
The project originally started as an effort to make a more configurable version of JSLint—the one that doesn't enforce one particular coding style on its users [...]
JSLint is just being picky here. The guy who wrote it also baked in many stylistic suggestions in order to keep his own code more consistent.
As for semicolon insertion, you shouldn't need to worry here. Inserting a semicolon before the else clause would lead to a syntax error and automatic semicolon insertion only occurs in situations where the resulting code would still be syntactically valid.
If you want to read more on semicolon insertion, I recommend this nice reference
Basically if you insert semicolons everywhere you only need be careful about putting the argument to "return" or "throw" (or the label for "break" and "continue") on the same line.
And when you accidentally forget a semicolon, the only common cases that are likely to bite you are if you start the next line with an array literal (it might parsed as the subscript operator) or a parenthsised expression (it might be parsed as a function call)
Conclusion
Should you omit optional semicolons or not? The answer is a matter of
personal preference, but should be made on the basis of informed
choice rather than nebulous fears of unknown syntactical traps or
nonexistent browser bugs. If you remember the rules given here, you
are equipped to make your own choices, and to read any JavaScript
easily.
If you choose to omit semicolons where possible, my advice is to
insert them immediately before the opening parenthesis or square
bracket in any statement that begins with one of those tokens, or any
which begins with one of the arithmetic operator tokens "/", "+", or
"-" if you should happen to write such a statement.
Whether you omit semicolons or not, you must remember the restricted
productions (return, break, continue, throw, and the postfix increment
and decrement operators), and you should feel free to use linebreaks
everywhere else to improve the readability of your code.
By the way, I personally think that the } else { version is prettier. Stop insisting in your evil ways and joins us on the light side of the force :P
I have just finished reading a book titled Mastering JavaScript High Performance. I speak under correction here, but from what I can gather is that "white space" does in fact matter.
It has to do with the way the interpreter fetches the next function. By keeping white space to a minimum (i.e.) using a minifier when your code is ready for deployment, you actually speed up the process.
If the interpreter has to search through the white space to find the next statement this takes time. Perhaps you want to test this with a piece of code that runs a loop say 10,000 times with white space in it and then the same code minified.
The statement to put before the start of the loop would be console.time and finally console.timeEnd at the end of the loop. This will then tell you how many milliseconds the loop took to compute.
The JSLint error/warning is suggesting to alter code to
// naming convention winner? it's subjective
} else if{
b = 2;
}
from:
}
else if{
b = 2;
}
It prevents insert semicolons; considered more standard & conventional.
most people could agree a tab between the
}tabelse if{
is not the most popular method. Interesting how the opening bracket { is placed (space or not) obviously both ar subjected
I just came across code that looks like this:
if (foo == "bar"){}else{
}
Is there a good reason for someone to write it that way instead of
if (foo != "bar") {
}
or am I just dealing with a raving lunatic (this is my assumption based on other things in the code).
[Edit]
There is no such convention in the JavaScript community. This is just bad code.
[Original "Answer" Below]
I prefer to use the following syntax when I am leaving a project:
if (foo == "bar") { /* 100 or so spaces */ } else {
}
The } else { segment is hopefully obscured off screen by text editors so that the code does the exact opposite of what it seems. This way I can ensure that the remaining development team curses my name and would never consider me for future development or support. =D
I don't see why JavaScript code should be different in this respect from any C-heritage language. I've not encountered this idiom before, and I really don't like it. I need to mentally parse the thing twice to make sure I've understood.
The only analogue I can think of is an empty default in a switch statement,with a copious comment to say "I thought about this and it's just fine."
If one of my developers wrote code that way, I'd throw it back at them with a reprimand and a copy of "Javascript: The Good Parts." I can't think of a single good reason for doing that.
Also, they should have written their comparison as if (foo === "bar"). Much better practice.
Edit a year and a half later:
Out of boredom I knocked together a jsperf just to see if there was any noticeable performance difference between the two methods shown in the OP, and [SPOILER WARNING] no there isn't.
http://jsperf.com/empty-blocks-in-if-else-statement
I have done it before.
This is when I might want to add some debug statements later.
Yes sure he could have done
if (foo != "bar"){
//something
}else{}
But isn't that just the same thing?
Back to the code you saw.
So what the programmer probably did is:
if (foo == "bar"){}
else{/*something*/}
Then later on when he wanted to add some debug information into the 1st part he would.
The logic still works and it is not flawed in the least bit. (in my opinion)
It's confusing for two reasons. The syntax is confusing because he's evaluating foo == bar just to do ... nothing? It seems unnecessary not to use the syntax you suggested. Visually it's also confusing because the empty block and the if evaluation are on one line, so if I were reading this code later I might gloss over things and assume the statement read as
if (foo == "bar"){
}
Which is the exact opposite of the code's intention. One possible explanation for this is that the programmer intended to go back and implement some code for foo == bar, but either didn't or forgot to do so.
My vote is for lunatic.
There is no good reason to do that.
On a side note, however, keep in mind that with loops there are sometimes cases where an empty block may be acceptable:
var i;
for (i = 0; document.getElementById("box" + i).value != ""; i++) { }
// do something with i
I tend to write chained if's like this:
if (a) {
} else if (b) {
// do something
} else if (c) {
// do something
} else if (d) {
// do something
}
Rather than:
if (!a) {
if (b) {
// do something
} else if (c) {
// do something
} else if (d) {
// do something
}
}
This makes the code more neat IMO.
Does it make sense?