Hi, I've got code like this: Code (csharp): { if( ... ) { var test; ... } var test; // error here, test all ready exists ... } Should the first test fall out of scope at the end of the if statement?
Yeah, but apparently not in the design of JavaScript. That's what I was told in my bug report. Sucks don't it? -Jon
That does suck. Why would JS stray away from the pack of almost every other OO or procedural language? It makes for loops where I use the generic 'i' a pain in the ass! Makes no sense...
I've found it convenient on a number of occasions to declare variables within an if... and then use them elsewhere. But yes, the generic 'i' thing can be irritating. Like most other design decisions, there are good points and bad points. --Eric
It's a little annoying, I agree, but it's easy enough to declare your variable before the condition/loop.
Read the first sentence of my last post. It's more convenient sometimes, and I prefer not to declare variables just for the sake of declaring them, without any meaningful value (although sometimes necessary for global variables). You can't do this in C#: Code (csharp): if (foo == 10) {bool bar = true;} else {bar = false;} if (bar) {print "Whoo-hoo!";} Instead, you would have to define bar as a bool before the first if statement, which to me is redundant code. On the other hand, you can't do this in JS: Code (csharp): for (i = 0; i < 10; i++) {print (i);} for (i = 0.0; i < 10.0; i += .1) {print (i);} Well, technically it will compile, but it won't do what you intended...it will freeze your program with an infinite loop instead. So I can understand the argument against this behavior...sometimes it is annoying, yes. However, I personally find it less annoying overall than the alternative. As another example, there have been a number of cases where I've used the last value of i from a loop, outside of that loop. There are of course ways around that with C#'s scope, but it's just more clean convenient this way. --Eric
Declaring variables inside if statements for use outside them is sloppy. If a variable is going to be declared either way (both if and else), it should be declared beforehand (because its declaration doesn't depend on the if statement). If the variable may or may not be declared, it shouldn't be referenced outside the if statement.
Not the same, but some practices are sloppier than others. I suppose there's not much harm in what you suggest if the code is a few lines long. Other than that, I see no benefit whatsoever. As someone else said, you can declare it once above the if-statement. You suggested that this leads to redundant code, but the alternative is to make it more difficult to see if and when variables are initialized. This can lead to bugs. It also makes it more difficult to reorder or transplant sections of code. Visual Basic allowed what you suggest, and in my experience (program with 200 forms, 10 years of maintainance and enhancements by a shifting team of programmers with varying degrees of experience) it occasionally led to bugs. VB's lax scope and other bits of non-strictness have a definite negative impact on large projects. Hope that helps you see where some of us are coming from.