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.
Related
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 was wondering why the following code is problematic to the CRA (and many other) js linter(s) by default. What I see here is a compact readable line of code. My guess is because the one liner below is not very scalable. Sometimes small simple chunks of code won't (shouldn't) need to get any bigger anyway. What other reasons are there to avoid writing simple one liners like this?
doSomething( prev => (prev.searchField = val, { ...prev }) );
Do I really need to do this to make the linter happy or are there other ways to keep the above one-liner?
doSomething(prev => {
prev.searchField = val;
return { ...prev };
});
To keep this succinct Lets not debate what is more readable just please answer why you think the linters warn this type of code with Unexpected use of comma operator no-sequences.
The ESLint rules are very customisable, to allow teams that have specific guidelines to customise the warnings and lintings so that they can begin to use the tool without having to edit all their previous code.
However, CRA and a few others come with recommended linter settings that are generally "best practise" and also prevent beginners making mistakes.
Although you may think that simple one liner is readable, for a lot of people it isn't, and so that no-sequences rule is a part of that pre-selected rule-set that you happen to be using.
If you disagree with the recomendations, then you are able to turn it off easily.
no-sequences rule in EsLint docs
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?
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.
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
In the languages like python, ruby, javascript, there is separate syntax for single-line and multi-line comments. I don't see the benefit of this complexity. Why, from a language design perspective, is there a distinction between the two? Using javascript as an example, here's the implementation:
// I'm a single-line comment!
/*
I'm a
multi-line
comment
*/
Why not simply (something like):
/* Just a comment */
/*
Doesn't matter
how many
lines
/*
People need to comment out blocks of code at once
People also need to comment out single lines
Commenting out a single line is faster when there’s only one change to make.
There are languages that only support comments with a starting and ending delimiter — C89 is a notable example (ever think C99 added // for a reason?). However, using the same starting and ending character would make a complete mess if you forgot to take one (or the other) out. Every comment following it would be flipped, and how would the compiler (if it’s a somewhat helpful one) know where the syntax error was?
One possible answer is that single-line comments are faster to add.
For example, in JS you need 2 special characters to add single-line comment and 4 to add multi-line comment.
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
What is better to use in javascript to square some value.
Math.pow
Math.pow((circle2.x - circle1.x), 2)
Or my own function
square(circle2.x - circle1.x);
function square(a){
return a*a;
}
It is nearly always better to use a library then write your own code, unless you have a good reason not to. Reasons why:
It saves you work.
It is well-tested code, while your code might introduce bugs.
Someone else who looks at your code will know what Math.pow is, so it makes your code easier to read.
Obviously this is a very simple case, in which your own function is unlikely to cause a problem. Still, it is better to get in the habit of using libraries whenever possible.
By the way, Math.pow performs a lot of handling of special cases. This illustrates that even a simple function can have more pitfalls than it appears at first. By using a library, you don't have to worry about handling all of the edge cases yourself.
You should always prefer to use library functions - what is the point in reinventing the wheel?
Library functions are optimized and may cater for some corner cases you are not aware of...
Are you going to provide own implementation of multiplication as well?
For a power 2 specifically I would use multiplication because you really don't lose any legibility. Even more if speed is important, multiplying will probably be faster than function calls.
edit: I mean don't even create a function... just a*a.