I'm not surprised it irritated you. Those errors are notoriously difficult to pin down, if only because it exactly the sort of thing you'd think you couldn't possibly mess up. (I'll leave it at that and let someone else claim the joy of discovery.)
If it makes you feel any better, just yesterday I was looking at some JavaScript code where someone made almost the exact same error ... only in reverse.
A few days before that, I had a loop that wasn't working properly.
while(some condition I can't remember); { //some conditional code }
I was smacking myself when I realized what I'd screwed up, there. (Hint: there's something there that doesn't belong.) I know better. That should never have happened, and yet it did!
i think this is the only bug i found though the code chunk is kinda big for my liking
trace("qi.charPopUpArray array length: " + qi.charPopUpArray.length + " " + qi.charPopUpArray)//shouldn't it have the ; as you guessed here? //qi.charPopUpArray array length: 0
@Daisy - Yup! Not sure how that got there, but it did, causing the loop to terminate and the rest of the code to execute, normally, whether I wanted it to, nor not.
@pheonix guy - Actually, it probably should have a semicolon, but that's not the error I found. (There's a problem with line 8, as well, and I suspect that was the big one.)
That's why you always want to write the constant on the left for compares if you can. Something like if(x == 5) can go wrong, but if(5 = x) won't compile. Still, it leaves you with the nasty case of if(x == y). Not a lot you can do to avoid mistakes with that one.
Actually, most of the time, you shouldn't be using literal values for comparisons, at all, if you can help it. Instead, you should define a constant or an enum somewhere, and use that, because if someone sees a 5, they have no way of knowing what that represents. 5 what? 5 elephants? 5 trampolines? Is that the age of your pet goldfish? How about the number of times you ate out this week?
On the other hand, if they see something like MAX_ITEMS, that actually provides some context, and knowing the actual number is usually a whole lot less important than knowing what that number means. Plus, something like MAX_ITEMS is likely to be exactly the same, no matter how many times you use is, but if circumstances ever change, and the cap is raised, you only need to change the 5 in "const int MAX_ITEMS = 5;" to something else, and that value will change in every place that uses MAX_ITEMS. It makes the code easier to read, and it's less error prone, because you won't risk overlooking an instance that used it, if you need to make a change.
That doesn't invalidate the main thrust of your argument, because a compiler will still throw an error if you try to assign to it, whether it's a literal (5) or a constant (MAX_ITEMS) ... unless you're dealing with a language like JavaScript that doesn't support constants. Creating variables to act as constants is still beneficial for all of reasons mentioned (readability & being less error prone, if you need to change the value), but you *never* want to put your constant on the left, because JavaScript doesn't care if you try to assign to it, accidentally. (In other words, it works, but it may be a bad habit that requires breaking, depending on what other languages you work with. Just something to consider)
@Hakker - it depends on which error you're talking about.
The semicolon, yes, Flash should point that out. The problem with missing semicolons is that, when they do cause problems, the compiler doesn't usually throw a fit until several lines later. It all depends on how the lines break up and whether the compiler can still make sense of them or not. Until the missing semicolon causes something else to completely fall apart, it'll keep going. That's been par for the course in just about every language I've ever used. (That's part of why they can be tough to track down. While the compiler flags an error, the actual problem is earlier in the code.)
If you're referring to the = instead of == thing ... no, the Flash will not point that out, because as far as the compiler's concerned, that's not an error.
if(x=y){//do some stuff}
is equivalent to
x=y; if(x){//do some stuff}
At least 99% of the time, that's probably not what you want (and if it is, you still probably want to split it up, if only to prove that it *was* intentional), but Flash (or any other compiler, for that matter) has no way of knowing that it's not one of those rare exceptions, so it isn't going to raise any flags over unusual (but perfectly legal) code.
If you actually meant the debugger and not the compiler, that's not how debuggers work. They don't identify errors for you. They just allow you to check on the status of your code as you walk through it, making it easier for you to find the problems, yourself ... provided you have at least some idea where to look, in the first place. It's an invaluable tool, but it's hardly automated enough to find problem for you.
Sorry if any of that comes across as a lecture, but they were good questions worthy of a proper response.
As a student, I find it very interesting, and am grateful of the long comment. Educational usually equates to helpful, so long as the topic is relevant.
I'm not surprised it irritated you. Those errors are notoriously difficult to pin down, if only because it exactly the sort of thing you'd think you couldn't possibly mess up. (I'll leave it at that and let someone else claim the joy of discovery.)
ReplyDeleteIf it makes you feel any better, just yesterday I was looking at some JavaScript code where someone made almost the exact same error ... only in reverse.
A few days before that, I had a loop that wasn't working properly.
while(some condition I can't remember);
{
//some conditional code
}
I was smacking myself when I realized what I'd screwed up, there. (Hint: there's something there that doesn't belong.) I know better. That should never have happened, and yet it did!
In short: you're not alone!
I'm assuming its the ;
ReplyDeleteDaisy
trace("qi.charPopUpArray array length: " + qi.charPopUpArray.length + " " + qi.charPopUpArray) //qi.charPopUpArray array length: 0
ReplyDeletei think this is the only bug i found though the code chunk is kinda big for my liking
trace("qi.charPopUpArray array length: " + qi.charPopUpArray.length + " " + qi.charPopUpArray)//shouldn't it have the ; as you guessed here? //qi.charPopUpArray array length: 0
@Daisy - Yup! Not sure how that got there, but it did, causing the loop to terminate and the rest of the code to execute, normally, whether I wanted it to, nor not.
ReplyDelete@pheonix guy - Actually, it probably should have a semicolon, but that's not the error I found. (There's a problem with line 8, as well, and I suspect that was the big one.)
hmmmmm == ; LOL did the same mistake last week too hahaha. what language is this reminds me of the C's.
ReplyDeleteweird doesn't actionscript have a debugger to catch such simple things?
ReplyDeleteHmm, i don't know AS, but i think its a problem that is not uncommon in C/C++ too, though there the compiler shows a warning (but still compiles).
ReplyDeleteThat's why you always want to write the constant on the left for compares if you can. Something like if(x == 5) can go wrong, but if(5 = x) won't compile. Still, it leaves you with the nasty case of if(x == y). Not a lot you can do to avoid mistakes with that one.
ReplyDeleteActually, most of the time, you shouldn't be using literal values for comparisons, at all, if you can help it. Instead, you should define a constant or an enum somewhere, and use that, because if someone sees a 5, they have no way of knowing what that represents. 5 what? 5 elephants? 5 trampolines? Is that the age of your pet goldfish? How about the number of times you ate out this week?
ReplyDeleteOn the other hand, if they see something like MAX_ITEMS, that actually provides some context, and knowing the actual number is usually a whole lot less important than knowing what that number means. Plus, something like MAX_ITEMS is likely to be exactly the same, no matter how many times you use is, but if circumstances ever change, and the cap is raised, you only need to change the 5 in "const int MAX_ITEMS = 5;" to something else, and that value will change in every place that uses MAX_ITEMS. It makes the code easier to read, and it's less error prone, because you won't risk overlooking an instance that used it, if you need to make a change.
That doesn't invalidate the main thrust of your argument, because a compiler will still throw an error if you try to assign to it, whether it's a literal (5) or a constant (MAX_ITEMS) ... unless you're dealing with a language like JavaScript that doesn't support constants. Creating variables to act as constants is still beneficial for all of reasons mentioned (readability & being less error prone, if you need to change the value), but you *never* want to put your constant on the left, because JavaScript doesn't care if you try to assign to it, accidentally. (In other words, it works, but it may be a bad habit that requires breaking, depending on what other languages you work with. Just something to consider)
@Hakker - it depends on which error you're talking about.
The semicolon, yes, Flash should point that out. The problem with missing semicolons is that, when they do cause problems, the compiler doesn't usually throw a fit until several lines later. It all depends on how the lines break up and whether the compiler can still make sense of them or not. Until the missing semicolon causes something else to completely fall apart, it'll keep going. That's been par for the course in just about every language I've ever used. (That's part of why they can be tough to track down. While the compiler flags an error, the actual problem is earlier in the code.)
If you're referring to the = instead of == thing ... no, the Flash will not point that out, because as far as the compiler's concerned, that's not an error.
if(x=y){//do some stuff}
is equivalent to
x=y;
if(x){//do some stuff}
At least 99% of the time, that's probably not what you want (and if it is, you still probably want to split it up, if only to prove that it *was* intentional), but Flash (or any other compiler, for that matter) has no way of knowing that it's not one of those rare exceptions, so it isn't going to raise any flags over unusual (but perfectly legal) code.
If you actually meant the debugger and not the compiler, that's not how debuggers work. They don't identify errors for you. They just allow you to check on the status of your code as you walk through it, making it easier for you to find the problems, yourself ... provided you have at least some idea where to look, in the first place. It's an invaluable tool, but it's hardly automated enough to find problem for you.
Sorry if any of that comes across as a lecture, but they were good questions worthy of a proper response.
Yikes! That was a lot longer than I thought it was!
ReplyDeleteSometimes I get going and don't know where to stop. Sorry!
As a student, I find it very interesting, and am grateful of the long comment. Educational usually equates to helpful, so long as the topic is relevant.
ReplyDelete