> From: Pops
> <snipped all the stuff I agree with :-)>
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.) You got us going on an interesting discussion of coding style
issues, but it's all under the subject "jQuery's Fearless Leader on
Ajaxian". I thought about changing the subject in my first reply, but doing
that breaks the discussion thread in some email programs. Better to do it
right from the start. :-)
Not a biggie, and I've "hijacked" threads myself, but starting a new thread
helps people follow the conversations.
> True, JS does not support local scoping, and this can get you
> in trouble in designs too - using the same variable name
> twice for two different things conflicting with your design
> intentions, but that is where the moduliztion comes in and
> helps resolves this conflicts.
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"
}
You can also use this to rename a variable inside a local scope, as seen in
the common plugin trick that lets you use $ instead of jQuery in your plugin
code - and provides you a local namespace to boot:
(function( $ ) {
var myLocal = 1;
$.fn.myPlugin = function() {
// logs "1" and didn't pollute the global namespace
console.log( myLocal );
};
})( jQuery );
> It is good practice to get use to the ideal of always
> initializing your variables. Many languages, especially
> those like JavaScript with RTEs (Run Time Engines), which
> typically automatically zero out all memory variables.
JavaScript initializes all variables to the "undefined" value, whose type is
"undefined".
> However from a programmer's system logic perspective:
>
> var currentEntry = 0; // currently selected table entry
>
> is "better" then
>
> var currentEntry; // currently selected table entry
Those are two different things. They both initialize currentEntry to
well-defined values. Neither one is better than the other, without knowing
more about the code that uses them.
Is currentEntry a numeric index? Sure, initialize it to 0 if that is the
value it needs.
Is currentEntry an object reference? Obviously you wouldn't initialize it to
0 in that case. Should you initialize it to null instead:
var currentEntry = null;
Or even to undefined:
var currentEntry = undefined;
You could, but why bother? I already know that "var currentEntry;"
initializes the variable to undefined (and if I don't know, I'd better
learn). Doing it explicitly doesn't add anything to my understanding of the
code.
> If someone every wrote a real compiler for JavaScript, the
> benefits of initialization will become very apparent. If the
> programmer switches languages alot, it is good practice to
> always think the same way.
I don't think so. There are a lot of basic coding principles that do carry
over to most languages, but you also need to take each language on its own.
In C, a variable will contain an unknown, arbitrary value if you don't
initialize it - not a good thing! In JavaScript, it will contain a specific
and well-defined value, the undefined value.
This particular thing is a pretty minor point, of course, but it's a good
example of where something that's important in one language may not matter
in another.
C, Java, and JavaScript make a fairly interesting case here, because their
syntax is so nearly identical but their semantics are so different.
-Mike
