I was just looking at the forum's HTML source*, and noticed some code that uses this syntax.
Basically it seems to be a surprising way of using the same elements that come into play with the more common {for (KEY in OBJECT)}
I realize now that it's probably a "safer" way of saying 'does OBJECT contain a property/method/value called "X", if you think "X" might ever have the value of 0 or "".
http://stackoverflow.com/questions/1119336/in-statement-in-javascript-jquery
Maybe I've just been an idiot for a long time, but instead of saying {if("getElementById" in document)...} I've been using the more common {if(document.getElementById)...} which should always be fine with METHODS.
However, I realize now that if I'm ever doing some kind of a "run only one time" kind of global flag or whatever, then {if(!"firstFlag" in window)} would be far better than {if(!window.firstFlag)} if there was ever the chance of firstFlag being 0 or "" #self-face-palm
PS: using Google to search for the definition/usage of the "in" js function is ... a challenge, shall we say? So here ya go:
https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Expressions_and_Operators#in
(and there's a neat/surprising/useful example using arrays here -- https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Expressions_and_Operators#Deleting_array_elements )
* if you're curious, this was the code that made me go "wuh? is that valid javascript?"
if ('XMLHttpRequest' in window)
{
...
}
You may like this actually, http://www.youtube.com/watch?v=taaEzHI9xyY
Some goodies in there that will make you think.
I'm not a big fan of Douglas Crockford, I think he's an arrogant jerk, but he does make some valid (and entertaining) points on usage (of which looping is but one)
:)
Nice finds.
I miss writing code, been debugging single-customer-single-environment-that-I-can't-access-directly bugs for a while now.
Well that sucks, you must be good at fixing bugs though they keep giving them to you! (I'M KIDDING!!)
:dance:
Quote from: Mr. Analog on April 11, 2013, 10:39:58 AM
Well that sucks, you must be good at fixing bugs though they keep giving them to you!
Hah, so true.
And all cool design projects eventually morph into support projects (unless you are a contractor lol)
Quote from: Mr. Analog on April 11, 2013, 10:54:13 AM
Hah, so true.
And all cool design projects eventually morph into support projects (unless you are a contractor lol)
A smart developer is not just good at coding, but at coding INTENTIONALLY BADLY (i.e. sub-par enough that bugs will occasionally but consistently crop up, slowly and over a long period of time, but well enough that the app basically works) ( ;) )
Like, what drug exactly do they put in the water there LOL
I enjoy doing things right even if I have to tear down half of what's there, I no longer have that fear, because I have lived with the consequences of 8 billion layered bandaids.
NEVER AGAIN
source: http://dilbert.com/strips/comic/1995-11-13/
-----
With the amount of development work always outstripping the number of available developers, I'd say a smart developer writes the best possible code so they can get paid to work on new projects instead of having to stick to old projects and old technology.
I hear ya, we have a guy on our team who through no fault of his own (well, let's call it attrition maybe) is now unhappily married to a codebase he doesn't want to maintain.
In the famous words of every developer everywhere, ever: we need to rewrite this app from scratch.
LOL