

How Good C# Habits can Encourage Bad JavaScript Habits - Marwan
http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/

======
oozcitak
I don't see why a person with a C# background would have any of these (2) "bad
habbits". On the contrary, someone with some C# experience would do his best
to avoid global variables, and one of the first things he would search for
would probably be how to do namespacing with javascript. The new keyword may
be an issue at the beginning but as soon as you do some JSON, you
automatically get the correct way of declaring arrays and objects.

~~~
brc
I came here to say the same thing : C# makes it intentionally very difficult
to create a global variable, and the first example is just a case of sloppy
coding, whatever the language. You cannot develop a habit of creating global
(or undeclared) variables if you're coming from a C# background.

Similarly, the global namespacing - a C# developer is going to look for ways
to declare namespace.definition style, and is not going to spontaneously come
up with namespace_definition, as this is an unseen pattern in C# examples and
general practice.

Perhaps it would be a good primer for a VB6 -> Javascript developer, but I
don't imagine there are too many of those around.

~~~
GFischer
"VB6 -> Javascript developer, but I don't imagine there are too many of those
around."

Why not? Some of us are (were) stuck maintaining bad VB6 apps and asp webpages
with vbscript that we had to migrate to javascript as Firefox doesn't support
vbscript.

I no longer do this, but it paid above average for my country and I was
starting out as a developer. And yes, my code probably did suck (heck, it
probably still does).

------
DrJokepu
I don't quite agree with everything the author said. For example, the new
keyword can make the code a lot more readable if you use it to call your own
constructors (that is, functions that assume that "this" is referencing a
newly created object).

Also, if you're dealing with DOM, you might want to avoid anonymous functions
and closures as IE tends to not do proper garbage collection within closures
and leak an awful lot of memory that doesn't get freed even after you visited
another page. (This is an oversimplification, Google "IE DOM memory leaks" for
a better description of the issue.) This is not JavaScript's fault, but still
it is an important thing to consider as your users will hate you if your site
is crashing their browser even if it's not your fault.

~~~
btilly
_Also, if you're dealing with DOM, you might want to avoid anonymous functions
and closures as IE tends to not do proper garbage collection within closures
and leak an awful lot of memory that doesn't get freed even after you visited
another page._

To the best of my knowledge this was fixed in IE 7. Therefore I consider
having such leaks on the general internet to be an underhanded service.
Anything that leaves IE 6 usable but less pleasant encourages people to
migrate to something better. ;-)

~~~
DrJokepu
It wasn't completely fixed in IE7, unfortunately:

" However, as some web developers have pointed out, those changes don’t solve
the problem entirely. IE still leaves behind anything not attached to the tree
when we tear down the markup. In addition, sites that users keep open for
extended periods of time, such as Web-based mail, can still cause IE’s memory
usage to continually grow if the site doesn’t take care to avoid the leak
patterns."

[http://blogs.msdn.com/b/ie/archive/2007/11/29/tools-for-
dete...](http://blogs.msdn.com/b/ie/archive/2007/11/29/tools-for-detecting-
memory-leaks.aspx)

It's still a major pain in the back.

------
jonpaul
Forgive me, but it's still not clear (in terms of the outcome) to me what the
difference is between:

var a = new Array(); and var a = [];

Would someone shed some light on this?

~~~
pmjordan
The outcome of those two is the same. Likewise the outcomes of

    
    
      var a = new Array(3, 4);
    

and

    
    
      var a = [3, 4];
    

are the same.

However,

    
    
      var a = new Array(3);
    

is not the same as

    
    
      var a = [3];
    

The former creates an array with 3 empty elements, the latter an array with a
single element initialised to 3. So the constructor syntax is dangerous to use
with just one argument. Plus, the literal is just easier to type and spot
visually.

There is a slight performance penalty for using named constructors: the
runtime needs to look up the "Array" entry in the scope; nothing (except
common sense) stops you from redefining it or shadowing it with a local
variable. The literal syntax can be resolved at parse/compile time.

Fun JS array fact: the implicit _arguments_ argument in each function looks
like an array but its prototype is actually not Array. None of the Array
methods work on it, although the special length property behaves as you'd
expect.

~~~
scott_s
_The former creates an array with 3 empty elements, the latter an array with a
single element initialised to 3._

Ugh. I can see that catching lots of people. Is new part of the language, or
part of jQuery?

~~~
user24
pmjordon has a great reply, but I'd like to add that I'm a little surprised by
your mention of jQuery... jQuery is just a framework built on top of
JavaScript; it's not like it's a different language or even a language
extension. It's just a standard piece of JavaScript code, an object which you
can use.

~~~
scott_s
I am unfamiliar with the details of JavaScript's semantics, so I won't be able
to tell at a glance what is part of the language and what is part of a
library.

------
emehrkay
Good C#|Java|Python habits == good MooTools habits

~~~
pmjordan
I found the C# link in the article to be tenuous at best. JavaScript doesn't
have namespaces or classes, so yes, obviously you'll need to do without them.
Global variables are discouraged in C# - in contrast, uh, avoid global
variables in JavaScript? Likewise, I wouldn't call creating objects using a
constructor a "best practice" if _that's the only way to do it in the
language_. Besides, there is a time and place for using _new_ , even in
JavaScript, mainly for creating functionality-heavy objects with a prototype.
(as opposed to data containers)

------
geuis
Overall the tips and explanations are quite direct and succinct, unlike so
many other poorly written tutorials. Its connection with C# is absolutely
missing though.

