Friday, January 18, 2013

Intriguing JavaScript (for a C# developer like me)

Following creates and calls the function, straight away.
})('hello world');

Following mean the same!
A) object1.function1(data1);
B) object1['function1'](data);

$ is a function name. It's not any special syntax. Rocket science $#@%^$

= = Vs = = =
True for the following
var a = 10 /*integer 10 */, b ="10" /*string 10 */;
alert(a == b);

False for the following
var a = 10 /*integer 10 */, b ="10" /*string 10 */;
alert(a === b);

Undefined Vs null 
var a; 
alert(a == null); //true
alert(a == undefined); //true

But initialization defines type of variable,
var a = 10; alert(typeof(a)); //number
var a = ''; alert(typeof(a)); //string
var a = null; alert(typeof(a)); //object
var a; alert(typeof(a)); //undefined

Wednesday, January 2, 2013


How would one approach trace information in development environments? Trace I mean any additional information about call-stack, function input, output etc. Classes in the application are coded with a specification in mind. In a simple example, a class named User could be intending to create, update, delete or select one or more users (CRUD). When the Create function is called, all required user details expected to be provided by calling function. Let's say calling function didn't provide first name, should your class handle it? In an end-to-end application flow, UI validations/service validations take care of it. Should it be done across layers? That's lot of redundant code for me. 

If UI validation didn't work correctly, how about finding it in development right on our face. If it did, we avoided a bug!

Will unit tests find such problems? I'll leave it to you to answer that question.

I would think, Symbols solve this problem. We can write code that works in specific environments only; In this case Development environment - Debug. Before and after every function, let's add code that runs in Debug mode only. This code doesn't run in QA, Production so on. Which means no redundancy (where it matters). Checks(validations) are everywhere, so a UI validation failure is seen early enough. But wait I said before and after every function? - Preconditions and Post-condition checks; Is the input as expected to the function, is the output as expected from the function?

Solution Configurations:
It acts like template of settings in Visual Studio solution. By default available settings are Debug and Release. Debug configuration has a symbol called DEBUG.

One can create custom configurations. For a given project, one can add symbols for that custom configuration

Pre-Processor Directives:
They start with a hash (#), generally work in combination with symbols. These are additional instructions to compiler in code.

Consider below code line, #if verifies specific symbol exists or not. On developer machine, in Debug configuration, DEBUG symbol would exist. On Production machine, in Release configuration it wouldn't.

Complete list of Pre-processor directives here (
System.Diagnostics.Debug class
Runs in debug mode, no need to use pre-processor directive as far as code is specific to Debug symbol.

For the above mentioned example on creating a customer, below statement alerts when required field was not provided and stops the solution from running. Developer can't miss the error.

Or do you want to approach by logging all these errors to event log? You can do that too - 

Just for fun, why not print to console?