When to use continue [closed] - javascript

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been reading JavaScript: The good parts. Theres a section: The Bad Parts. This is straight from the book:
continue Statement
The continue statement jumps to the top of the loop. I have never seen a piece of code that was not improved by refactoring it to remove the continue statement.
So my question is, is there ever a situation continue is required?

There are strong opinions on both sides, wether continue is useful or not. But it is never required. You can always find a way around it, if you want.

There are some believe that if there is a continue in your loops, that it should probably be refactored or rewritten. There are legitimate uses of continue, but they can usually be avoided. To give an example:
for (var i = 0; i < particles.count(); ++i)
{
if (OutOfBounds(particles[i])) {
RemoveFromArray(particles[i]));
++i;
continue;
}
}
In this case, the continue is unnecessary because there is nothing else in the loop, but it would be if you were to do something else after the initial check.
Also, it helps with readability, if you have a complicated loop with nested conditionals. For example, you may have a bunch of extraneous variables like quitLoop1 and quitLoop2 and so on.

In my experience, the continue statement is useful if a condition in a loop is met, and you don't want to execute the rest of the code in the loop on that iteration. The reason why you'll get mixed opinions on its usefulness is that many will argue there are better ways to rewrite your code so you don't have to use it. In my opinion that argument is strictly for readability purposes.
I have never used continue in javascript because most of the javascript I write is simple DOM manipulation. However, I have used continue in various Python programs, and it can be useful (as mentioned above) to skip over the loop under certain conditions.

Related

Is await considered a bad coding practice? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm new to asynchronous programming and I would like to know if using await is considered a bad coding practice. I am asking this because it looks like it is possible to let the callback function do the waiting instead of letting the entire program suspend everythng until the rpocess complete.
Thank you and I appreciate your idea on this.
No, it’s not. It’s just an approach (very useful sometimes).
In modern systems complexity is so high, that in many cases having clear code is much better that having super effective code. Just an example: imagine the case when you need to make several async things one by one (maybe, fetch data based one previously fetched results). You can do it making a chain of several .then(). After that you’ll need to also add .catch(). And at this point you’ll find yourself writing spaghetti code which is a bit messy.
The other option is just make this async function with sequential calls and some logic between them. And this will look much better

Why forEach return void? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm using Typescript for a Node application and I love to fully use the power of Javascript with all the good stuff of Typescript. Line after line I took up the habit to chain functions, to use arrow functions, to user carrying and partial functions and so on.
What I really cannot understand is why the forEach function return void instead of something useful I can use to perform a chainable, just one-line and elegant piece of code.
My question is about the design considerations behind this choice that at first glance seems to be just annoying and the implications a return value can cause.
Because that's what forEach does. It's like a for loop; it isn't meant to evaluate to anything useful. It's intended to be used to carry out side effects using a function. If you need it for anything other than that purpose, it's the wrong tool for the job.
If you want a looping function that evaluates to something, use map or reduce instead. map will return a new list based on the old list, and reduce will return a reduced value from iterating over the list.

Are ternary function executions better or worse than if statements in JS [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been looking on stack overflow and searching blog posts for info on this and can't seem to find a definitive answer.
It regards using if condition or a ternary to execute functions. Is there a "best practice" regarding which we should use?
Let's say we have 2 functions and that one of them will execute based on some boolean value.
We can write functionality like this using traditional if/else statements:
if (boolean) {
doThis()
} else {
doThat()
}
Alternatively, we can write something functionally equivalent like this:
boolean ? doThis() : doThat()
Generally, most ternaries I use and see from others are used for assignment, and not to execute functions.
Everything on stack overflow and blogposts that I've seen just state that, "Yes, that's a thing. We can execute functions in ternaries".
Nothing ever speaks to whether we should favor one over the other. Is there a best practice when it comes to which one you should choose?
It seems like it'd be completely fine to use one if the functionality you'd like to execute conditionally is just one function. If you have more then that it seems like if conditions should be favored for readability.
So, with all that context, here's the question:
Does it just depend on the situation? Or should we always favor if conditions for function calls and relegate ternaries strictly to assignment?

What is the downside of using one-line if statements? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I see most code-bases using bracketed if-statements in all cases including cases in which only one statement needs to be executed after the if.
Are there any clear benefits to always using bracketed if-statements or has it just become a standard over time?
What is the general consensus on this, would it be a big mistake to allow one-line ifs through our linter?
Largely this comes down to developer preference, although many reasons are given for using the curly braces on every control block.
First, it makes the control block more readable. Consider:
if (some_condition)
runSomeFunction();
runSomeOtherFunction();
Since indentation is not respected in most curly brace languages, this will work, but it really reduces the readability (only runSomeFunction() will happen in the control block). Compare to:
if (some_condition) {
runSomeFunction();
}
runSomeOtherFunction();
Second, when you need to add something to the control block (which almost invariably happens more often than not), adding the curly's can be frustrating or easily forgotten leading to issues like the above.
Still, those largely come down to preference and you can always find exceptions (like if (some_condition) runSomeFunction(); which is much more readable than the first example above while still accomplishing the same goal in a much more concise format that retains readability).
If you have to go back to the code to add something, you might forget that you didn't open brackets, and your code wouldn't work if you exceed one line.
Other than that it's a matter of preference and format.

Generic functions: JavaScript or PHP? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
While working on a recent project, I began wondering when somebody may use JavaScript vs. PHP for a generic function. Take this basic function (in JS) as an example, which simply returns whether or not a number falls within a particular range:
function range(num, var1, var2) {
if ((num >= var1) && (num <= var2)) {
return true;
}
else {
return false;
}
}
For something that doesn't query a database, nor is it information that should be — or needs to be — indexed for SEO (I know by default JavaScript will not be indexed), then my inference would be that JavaScript would be sufficient. But at the same time, PHP could be as well.
Basically, if the ONLY point of the application were a simple function like above (not that I can see a reason for that, but I digress...), then which langauge would be better to write this in? JavaScript or PHP?
Would love any insight as to which would be the best method to use and why. I recognize there is no right or wrong answer necessarily, but would like to hear arguments for or against one over the other.
Thanks!
As you point out, there is no necessarily right or wrong answer.
I would say that it depends:
-Is it a problem for people to be able to reverse engineer the code?
-Is it a problem if it does not execute because JavaScript might be disabled?
-Is it preferable to have code execute client-side versus server-side from a performance point of view?
-Does the content generated by the output of this function qualify as something you might want indexed by Search Engines?
Depending on the importance of the above criteria/questions, JavaScript might be disqualified.
From the points above, the common thing seems to be that choosing for JavaScript is more likely to lead to potentially undesirable side-effects.
The safest bet, from what I theorize, is therefore the server-side language, PHP.

Categories

Resources