> > From: Michael Geary
> > Before I forget, Hector, in the future could you start a new thread
> > for a new topic like this? (And don't just change the subject line -
> > start a new message.)
> From: Pops
> Ok, I will make it an effort to live the same "topic rules"
> we also impose in our own support forums. But frankly, I
> must say, you are beginning to annoy me with your not once,
> not twice, not three, but now the forth time you are in one
> way or another moderating or pointing out some silly thing to
> me. The decision to change topics is highly subjective, but
> yes, I know better to do it the appropiate time. I just
> didn't and it also cross my mind that someone else might do
> it depending on deep it got. So please stop. Its annoying.
My friend, the only other message I've posted to you that was anything like
"moderating or pointing out some silly thing" was this one:
> First, let's call it jQuery, not JQUERY, so no one thinks
> you're shouting. :-)
I have no idea what the other messages you're talking about are, but they
weren't from me.
I thought both of those were perfectly reasonable suggestions, and I wasn't
disrespectful toward you in any way - especially when you take this in the
context of all the helpful messages I've posted for you.
But if you see it differently, I apologize. (And if you want to discuss it
further, let's take it offline to not bore the group.)
> > Not a biggie, and I've "hijacked" threads myself, but
> > starting a new thread helps people follow the conversations.
> Sure, but believe it or not, the odds are extremely high I've
> been cyberspacing far longer than you, maybe not,
> nonetheless, I know everything there is about it. I've been
> developing mail products (at all levels) since the 80s and
> you not going to find many people out that match my
> credentials in this area.
Cool, I'm glad I'm not the only old-timer here. I've been online since 1968,
worked at an early timesharing company during the 70's, and I wrote the
first email client for PCs in 1982. It had a complete GUI using character
mode graphics and supported all the email services of the day along with
point-to-point email transfers.
> > Actually, JavaScript *does* support local scoping, it just
> > doesn't do it at every curly brace. Every nested function
> > has its own local scope, and you can use an inline
> > anynomous function to introduce a local scope anywhere
> > you want:
> >
> > function test() {
> > var i = 1;
> > (function() {
> > var i = 2;
> > console.log( i ); // logs "2"
> > })();
> > console.log( i ); // logs "1"
> > }
> Not the same. You modularized the code, thus creating a new
> function stack prolog and epilog.
I don't follow you here. It's just an example of how you would translate a C
idiom (forgive me if the syntax is off, my C is rusty):
function test() {
int i = 1;
// nested scope
{
int i = 2;
log( i ); // logs "2"
}
log( i ); // logs "1"
}
into JavaScript. The nested anynomous function introduces a local scope that
works just like the inner block in C. (The syntax and implementation are
different, of course, but the concept is the same.)
> > JavaScript initializes all variables to the "undefined"
> > value, whose type is "undefined".
> I believe you nean undefined not the string "undefined."
It's funny you should mention that, because I actually paused when I wrote
it and thought about whether I should use the quotes or not. For the first
"undefined" (the "undefined" value) it was a tossup, but for the second one
(whose type is "undefined") I did use the quotes deliberately:
var foo;
alert( typeof foo ); // "undefined"
alert( typeof typeof foo ); // "string"
So, there is a type whose name is literally the string "undefined". That
type has a single value, which we call the undefined value (or "undefined"
value, take your pick). But that value doesn't actually have any name or
symbol in the core JavaScript language.
For convenience, modern browsers define a window.undefined property which
contains this "undefined" value. jQuery also defines this property for older
browsers:
window.undefined = window.undefined;
> which is internal constant for null which in most language
> is a zero value concept.
Not in JavaScript. The undefined value is not the same as null, and neither
is the same as zero. The == operator does type conversions that cause null
and undefined to compare equal. That's why your comparisons below work the
way they do. If you use the strict === operator, then undefined and null are
not equal.
> In other words, if you expected to
> be null, this is to common practice:
>
> var i;
> if (i == 0) alert("i is zerol"); // false
> if (i == null) alert("i is null"); // true
> if (i == undefinedl) alert("i is undefinedl"); // true
> if (i == 'undefined'l) alert("i is 'undefined'"); // false
>
> which is correct, Most RTEs will load low (zero out). Some
> systems will even load high, like a heap manager to help find
> leaks, overflows, underflows, etc, but when a uninitialized
> variable is referenced, it should be a null value.
>
> So its always better to initialize your variables, unless you
> specifically are designing for null.
>
> ...
>
> Initialize now, and you will have full confidence of your
> code behavior and others will gain more respect for the QA of
> your code as well.
>
> ...
>
> Write a compiler for JS, like I have for few languages, and
> you will appreciate what I am talking about.
I've written a few compilers too. But they weren't JavaScript compilers, so
my experience with them has no bearing on best practices for JavaScript.
My point was simply that this code:
var foo;
*does* initialize foo, to a completely specified and well defined value.
It's exactly the same as writing:
var foo = window.undefined;
It's nothing like C, where "int i;" results in an unknown and unpredictible
value. There's no such thing as an uninitialized variable in JavaScript.
> > C, Java, and JavaScript make a fairly interesting case
> > here, because their syntax is so nearly identical but their
> > semantics are so different.
> Mike, it doesn't matter what language you use. Coding
> guidelines are universal. If you ever did work for the
> governament, you would know the same rules of coding applied
> for any language being used.
Why would I care what the government says? I don't write code for them. :-)
Coding guidelines can't be universal, because different languages are not
the same. Where the languages are similar, sure - you can do the braces and
indentation the same in any of the C-like languages. And basic stuff like
"use self-explanatory names" is universal. But where the languages differ,
you can't assume that best practice in one language is also best practice in
another.
I had a manager once - a brilliant C++ programmer - who saw me using
closures in my JavaScript code. He freaked out, asking, "How can that
possibly work? Is it a bug? If it works, it must be just a lucky coincidence
or something!" I explained that it was a standard feature of the JavaScript
language, and he said, "Well, we can't use that. C++ programmers won't be
familiar with it and will be confused by it. We need to change everything to
use regular objects with 'this'."
So, we gave up using one of the best, most powerful features in JavaScript,
and wrote longer, more complicated code, all to make JavaScript look more
like C++.
The JavaScript DOM is an even better example. It was designed so that you
could write the exact same code in either JavaScript or Java. As a result,
it makes notoriously poor use of the JavaScript language. Everything is
driven by tedious function calls instead of taking advantage of native
JavaScript features.
To wrap up, I don't care at all if you prefer to explicitly initialize all
your JavaScript variables. Why would I? It's your code! :-)
My only suggestion is to make JavaScript coding decisions based on whether
they make your *JavaScript* code more readable, faster, and more reliable
and maintainable, not because it would be good practice in some other
language that you're not coding in.
-Mike
