Bad Practices
1. Having Variables & Functions in Global Scope
A best practice in C# is to limit the use of global variables. This doesn’t necessarily translate into a bad practice in JavaScript, but most C# developers are not aware of how easily it is to pollute the global namespace with needless variables and functions.
One way you can pollute the global namespace is to not declare your variables. In JavaScript, if you don’t declare your variables then they become globally available to the rest of the program, which is probably not what you wanted and generally a bad idea.
Coming from a C# background, you are most likely used to the concept of namespacing your classes so they won’t clash with other libraries. In the same way you should be mindful to not declare variables or functions in the global namespace to prevent clashing with other libraries, browser extensions, and also your own code.
Object Literal (All Public)
An Object Literal is a convenient way to create new objects. The syntax looks very similar to what you might expect to see in JSON (JavaScript Object Notation), but they are actually quite different. For more information about this you can check out an in-depth discussion on it by Ben Alman entitled There's no such thing as a "JSON Object".
When you create an Object Literal you can provide properties and methods and they can refer to each other. You can also add additional methods and properties to the object after it has been defined. All the properties and methods that you declare in the Object Literal are publicly accessible to the rest of your JavaScript code.
//Object Literal declaring properties and methods var skillet = { //public property ingredient: "Bacon Strips", //public method fry: function() { console.log( "Frying " + this.ingredient ); } }; console.log( skillet.ingredient ); //Bacon Strips skillet.fry(); //Frying Bacon Strips //Adding a public property to an Object Literal skillet.quantity = "12"; console.log( skillet.quantity ); //12 //Adding a public method to an Object Literal skillet.toString = function() { console.log( this.quantity + " " + this.ingredient ); };
2. Not Declaring Arrays & Objects Correctly
JavaScript is a prototypal language and not a classical language like C#. Although JavaScript does have a new operator which looks a lot like C#, you should not use it for creating new objects or arrays.
What Not To Do
You might be tempted to use the
new
keyword to create your objects in JavaScript.//Bad way to declare objects and arrays var person = new Object(), keys = new Array();
The
new
keyword was added to the language partially to appease classical languages, but in reality it tends to confuse developers more than help them. Instead, there are native ways in JavaScript to declare objects and arrays and you should use those instead.Preferred Way
Instead of using the previous syntax, you should instead declare your objects and arrays using their literal notation.
//Preferred way to declare objects and arrays var person = {}, keys = [];
Using this pattern you actually have a lot of expressive power using Object Literals and array initializer syntax. As we mentioned earlier, you should be careful to know that Object Literals are not JSON.
//Preferred way to declare complex objects and arrays var person = { firstName: "Elijah", lastName: "Manor", sayFullName: function() { console.log( this.firstName + " " + this.lastName ); } }, keys = ["123", "676", "242", "4e3"];Best Practice
You should declare all of your variables using their literal notation instead of using the
new
operation. In a similar fashion you shouldn’t use the new keyword forBoolean
,Number
,String
, orFunction
. All they do is add additional bloat and slow things down.The only real reason why you would use the new keyword is if you are creating a new object and you want it to use a constructor that you defined. For more information on this topic you can check out Douglas Crockford's post entitled JavaScript, We Hardly new Ya. skillet.toString(); //12 Bacon Strips
You can execute and modify the above code from jsFiddle.
The above code declares a skillet
variable and sets it to an Object Literal with one property (ingredient
) and one method (fry
) that are both publicly accessible off of the object. You can also add additional public methods and properties to the object after the initial declaration as shown above when adding the quantity
property and the toString
method. The toString
method is able to access the properties of the skillet
object since all of it’s parts are public.
Pros
- Cleans up the global namespace by adding a namespace to your properties and methods
- You can add functionality to the object literal at a later point
- All the properties and methods are public
Cons
- Uses the Object Literal syntax to define your properties and methods that some may find cumbersome
- There isn’t the ability to have private properties or methods