Monthly Archives: February 2009

JavaScript Date Object and Code Convention

“is Code Convention important?”, I couldn’t find better time to answer this with a big, decorated, shiny, flashing “YES” more than now!

I was doing some coding with JavaScript in which I needed to create a Date object and add to it 30 days, simple job! So I did the following:

    var x = new Date();

    x.setFullYear(2009, 3, 12);//Create date 12th of March, 2009

    x.setDate(x.getDate() + 30);

    document.writeln(x);

Great, when I checked the result it was: “Tue May 12 … 2009“! OMG why May?!, where did the additional month come from?! if I am in 12th of March and I add 30 days I expect it to be 11th of April, what is going on?!

God knows how much time I spent checking that cheesy 3rd line in my code, what could be wrong in it? maybe the “getDate()” doesn’t really return the proper type needed to set a new date? I tried all various ways doing it, checking many “solutions” scattered all over the web.

[Give your self sometime to figure it out before continue reading].

Well, the problem actually wasn’t in the 3rd line at all, it was in the 2nd! see that 2nd parameter with the value “3”? it is 0-based numeric! why on earth would it be 0-based?! any sane developer who never knew this fact would instantly deal with it “3 as March”.

Code Convention is as important as documentation; if I need documentation to know how to deal with piece of code and save me time to figure it out, Code Convention is as important.

Beware of Static Constructors

In Bunian we needed to use a static constructor for some reason, it was all going good; we tested the code and it ran smoothly…excellent (Code Coverage anyone?!).
But when I came across this situation, it appeared that the static constructor wasn’t invoked!even when “Class.Method();” is called! so lets examine it.

I have two simple classes as an Example:

public class Parent

{

    public static string DoSomething()

    {

        return “Parent: DoSomething() called”;

    }

}

public class Child : Parent

{

    static Child()

    {

        Console.WriteLine(“Child Static constructor called”);

    }

 

    public static string DoSomethingDifferent()

    {

        return “DoSomethingDifferent() called”;

    }

}

As it may be obvious, Child inherits from Parent, Child has a static constructor that we need to be executed when ever a method is invoked by Child. Now lets check the main program executing these two lines:

Console.WriteLine(Child.DoSomething()); //This code will NOT invoke the static constructor

Console.WriteLine(Child.DoSomethingDifferent());//This code WILL invoke the static constructor

The surprise (at least to me) when calling “Child.DoSomething()” the static constructor isn’t invoked! because it is in the parent!! aaaaaah! bad!! that was serious for our architecture  and we had to do lots of fixes to turns things around the right way (which I think it was for our own good for other reasons :P)

This brings up the Code Coverage topic as well; in our case that static constructor’s job was to create an instance of a member that is only needed once, and we check on it in other times by “if _instance != null”. It always ran ok because all the test code we created used to call an original Child before calling any other method that resided in the Parent.

bottom line: be ware of static constructors, and check your test code…it maybe hiding “surprises” for you 😉