Wednesday, April 23, 2014

Why need Closure in JavaScript

Safe and faster
var names = ['zero', 'one', 'two',  'three', 'four', 'five', 'six',  'seven', 'eight', 'nine'];
var digit_name = function (n) {
 return names[n];
alert(digit_name(3)); // 'three'

//Problem: not safe. It is global variable, other code could change it

var digit_name = function (n) { 
 var names = ['zero', 'one', 'two', 'three', 'four', 'five', 'six', 'seven', 'eight', 'nine']; 
 return names[n];
alert(digit_name(3)); // 'three'
//Problem: Safe but slow. Names hide in function scope, but need to initialize every time

var digit_name = (function () {
 var names = ['zero', 'one', 'two',  'three', 'four', 'five', 'six',  'seven', 'eight', 'nine'];
 return function (n) {
 return names[n];
alert(digit_name(3)); // 'three
//Safe and fast 

But why closure version code is faster?

Why Most Unit Testing is Waste

Keep regression tests around for up to a year — but most of those will be system-level tests rather than unit tests.
• Keep unit tests that test key algorithms for which there is a broad, formal, independent oracle of correctness, and for which there is ascribable business value.
• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system test — context is everything.
• Design a test with more care than you design the code.
• Turn most unit tests into assertions.
• Throw away tests that haven’t failed in a year.
• Testing can’t replace good development: a high test failure rate suggests you should shorten development intervals, perhaps radically, and make sure your architecture and design regimens have teeth
• If you find that individual functions being tested are trivial, double-check the way you incentivize developers’ performance. Rewarding coverage or other meaningless metrics can lead to rapid architecture decay.
• Be humble about what tests can achieve. Tests don’t improve quality: developers do.

Play video in Html 5