JavaScript for OO programmers, Part 2 – Things to watch for


JavaScript, as we shall see, has many peculiarities which distinguish it from languages that OO devs are familiar with. Being aware of these peculiarities will help you, dear reader, in navigating the labyrinthine foibles of my favourite programming language. Therefore, I shall attempt herewith to enumerate these vagaries, that you may not fall into the fiery pit of despair and instead ride the chocolate rollercoaster to the squeaky-clean apogee of true JavaScript demigod, total spiritual creaminess and avoid the chewy chunks of degradation.

#1: Equals

Take the piece of code below;


    '' == '0' // false
    0 == ''; // true
    0 == '0'; // true

Screwy right? The reason for this particular little piece of craziness is that the double equals operator in JavaScript implies Type Coercion. What this means is that it behaves correctly when the values are of the same type, but when they are not, it tries to convert the value on the right hand side of the comparison to the type of the value on the left. In the above example, the first expression evaluates as it should because both operands are strings. In the second example, it converts the empty string to the number equivalent 0 because it is a ‘Falsy’ value (more on falsy values later). And in the last example it simply converts the string ‘0’ to the numeric value 0. That comparison would return false in C#.

How to get around it:

Always, ALWAYS use the type-safe operators, !== and === to compare two values. These behave exactly as you would expect coming from an OO background.

#2 Evil = Eval()

Older JavaScript code can sometimes be riven with eval() statements as programmers were trying to dynamicise their code and eval() provided a convenient way to do so. Unfortunately there are lots of things wrong with this approach. One, it’s slow. Two, it’s unsafe. The code executed in the context of an eval() statement is given too much authority. File under “Plague, avoid like the”.

#3 Scope

Scope, in terms of a programming language, is the system of rules which govern the visibility and lifetimes of variables declared in your program. Now, if you’re coming to JavaScript from C# or Java, then you’ll be used to block scoping. The rules for block scoping are easy to understand and well defined. They also promote structured, easy-to-understand code.
But JavaScript is a little trickier. In JavaScript, scope is kept within functions, but not within blocks, such as if or while constructs. Have a look at the following code;


  // this is a global variable
  var test = "test value";			
  if(true){
    var test = "new test";
  }

  alert(test); // new test			
  
  // define a function with a locally-scoped variable
  function alterTest(){
    var test = "old value";
  }

  alterTest(); // call the function
  alert(test); // still equal to "new test"

Another thing to be aware of is that the scoping mechanism doesn’t work like this if you forget to use the “var” keyword. If you don’t use “var”, then the variable gets shoved into the global scope no matter what. Observe;


  function globalTest(){
    globalVar = "global value"; // this creates a globally-scoped variable - not the desired effect
  }
  
  globalTest();
			
  // the variable is now in the global scope
  alert(globalVar); // "global value"

Advertisements

About this entry