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
I have a student who likes to wrap large sections of code in curly braces so he can collapse those sections in the code editor. Initially, I balked at it, but couldn't think of a legitimate reason not to allow him to do it. I'm wondering if this practice will create any problems later on.
Example:
var a = 0;
var b = 1;
{ if (a == b){
alert("a = b");
}
else if (a > b){
alert("a > b");
}
else if (a < b){
alert("a < b");
}
}
I know there's a debate about braces around single statements inside an if, that's not what I'm talking about. I'm talking about the "parent" braces, if you will, around the series of if/else if statements.
As deceze indicated in his comment, you are incorrect about the braces limiting the scope of the variables.
var a = "outside";
{
var a = "inside";
var b = "another inside";
}
console.log(a); // prints "inside"
console.log(b); // prints "another inside"
Having said that, if you need to add in braces to make the code easier to navigate (read: ignore) it's a sign that the function is too long and should be broken apart into well named functions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I recently came across a question in an interview and am stumped at how to solve it. I would really appreciate any assistance.
The question asked me to create a function that received a number as a parameter (599) and returns a different number, but will also work in reverse. The issue is that I was not permitted to use any sort of conditional operator e.g. if, switch etc...
This was as far as I got:
function changeValue(v) {
// return 599 if 395 passed and vice versa
}
Use an object
function changeValue(v) {
const obj = {'395': 599, '599': 395};
return obj[v];
}
console.log(changeValue(395));
console.log(changeValue(599));
how about this:
function changeValue(v) {
return (599 + 395) - v;
}
from a programming perspective, this isn't as good a solution as the one that uses an object, because an object (map/dictionary) is easier to extend to other values.
Apart from the explicit memoization of the argument-result-pairs in an object (see other answer) you may use a linear function (remember it from math classes) f of the form f(x)=mx+b satisfying f(599)=395 and f(395)=599.
Solving this gives: m = -1, b = 994
function changeValue(v) {
return 994 - v;
}
console.log(changeValue(395));
console.log(changeValue(599));
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 have a question.
For example I use for loop like this:
for ( var i = 0; i < some_length; i++ ) {
/* some code */
}
After that variable i is hoisted.
Does it mean that I always should declare i variable at the beginning of the scope?
var i;
for ( i = 0; i < some_length; i++ ) {
/* some code */
}
UPD:
I know that both loops work the same way.
I mean which one is more correct?
Modern JavaScript supports block scoping via let.
for ( let i = 0; i < some_length; i++ ) {
/* i is defined here */
}
/* i is not defined here * /
Back to the original quetion: which example is more correct?
I would argue that the second one is less error prone.
In your example - first one is classic type declaration of your iterator variable. In other cases like when you operate on many functions/objects/variables i recommend you to declare all variables on the beginning of your scope/object/function.
When you see code wrote in that way in future it will be much easier to see what is going on in here. You just look on first 10-15 lines of code and you would not search for every variable inside - everything will be explained in the beggining of your code.
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 7 years ago.
Improve this question
I've been reading his book and he does stuff like this is a lot. For example, on p. 48 of JavaScript: The Good Parts, he has the function
Cat.prototype.purr = function ( n )
var i, s = '';
for ( i = 0; i < n; i += 1 )
{
if (s) {
s += '-';
}
s += 'r';
}
return s;
}
where the if conditional if essentially useless since it returns true every time but the first. The function could be written equivalently
Cat.prototype.purr = function ( n )
var i, s = 'r';
for ( i = 2; i < n; i += 1 )
{
s += '-r';
}
return s;
}
for better performance. Also, why does he define i outside the for loop?
The two functions are not the same. The original function returns an empty string of n is 0. Your function returns "r" if n is 0;
I am guessing that this is just an example to illustrate a common need where you want to separate a list of items with a character like '-' or ','.
You might write a loop like this and instead of 'r' you would have the names of items. E.g. "Bob-Mike-Jill-Jack"
To simplify the example for the book then he has just used 'r' which means the code could be written a different way like you say. But for a generic list you do want to add the separator every time except the first.
In regards to the var placement if you are declaring s then it is less chars to declare i there as well rather than write out var again in the loop. But I suspect it is probably just his idea of good practice to declare all variables that you use at the start of the function.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
can any one tell me how to de-obfuscate this?
É=-~-~[],ó=-~É,Ë=É<<É,þ=Ë+~[];Ì=(ó-ó)[Û=(''+{})[É+ó]+(''+{})[ó-É]+([].ó+'')[ó-É]+(!!''+'')[ó]+({}+'')[ó+ó]+(!''+'')[ó-É]+(!''+'')[É]+(''+{})[É+ó]+({}+'')[ó+ó]+(''+{})[ó-É]+(!''+'')[ó-É]][Û];Ì(Ì((!''+'')[ó-É]+(!''+'')[ó]+(!''+'')[ó-ó]+(!''+'')[É]+((!''+''))[ó-É]+([].$+'')[ó-É]+'\''+''+'\\'+(... Masked for confidentiality reasons
Look for the "()" in the end. Those are for executing the obscured function code. If you remove the last one and use "toString()" instead in node you will get the following (After formatting a bit):
function anonymous() {
na = prompt('Entrez le mot de passe');
if(a == 'I changed this to not make it too easy for you' {
alert('bravo');
} else {
alert('fail...');
}
}
Try it yourself, but always be careful, since if you are not careful this kind of code can run harmful stuff on your computer.
PS: A few more words about how it actually works. Those weird french seeming letters everywhere are just variables, which are defined in the beginning. É for example has the value of 2, since using the bitwise not operator on an empty array results a -1, and -~-(-1) = 2. All those backslashes are then used in combination with this numeric variables to get characters which eventually form the code of the function.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
Writing a function in JavaScript. The plan is the function creates an object, which requires boolean statements as parameters. Something like this ->
var foo = new fuzz("pie < squirrel", "monkey === banana");
My question is - Is this evil?
*Note - * Inside the function 'fuzz' I will run checks on the values of the parameters. (Check string.length etc). I think this is how one is meant to use eval, it just has such a bad reputation on t'up web.
Thanks
Summing up the conclusions in the comments: write a simple rule evaluation engine! E.g.:
var variables = { ... };
function niceEval(condition) {
var operands = condition.match(/(\w+)\s+(\S+)\s+(\w+)/);
switch (operands[2]) {
case '<' :
return variables[operands[1]] < variables[operands[3]];
...
}
}
This also gives you a lot more control over possibly occurring errors than blindly evaling a string.