Refactoring 101

I recently inherited a QA (Quality assurance) project from another developer and been assigned to build upon it. I found the project very complicated and not very maintainable. My first thought was to completely rewrite it but this option was out of the question since this project was on the high priority list and needed to be out the door.
So what do you do? Refactoring 101
Starting from the highest level I spent my first 2 days drawing out diagrams of the database and reverse engineering the code into UML diagrams to get a better understanding of this monster. After about 3 days I had a fairly good understanding of this tightly coupled code and was ready to dive in.

My first step was to separate the business logic from the client side. .NET allows us to do this by using the code behind model.

My next step was to clean up the client side javascript code by introducing jQuery. jQuery has a very rich event related function which allow you to bind events to elements in multiple ways. The big advantage here is that you bind the events at the top of your page and make it more readable.
For example:

//bind all your events on ready

  $(document).ready(function(){
  $("#btnUpdateUser").click(function () {
   //not implemented;

});

The code is now more readable, you don't have to jump all over the page just to see what btnUpdateUser does on a click. There is a lot more I did with jQuery but I'll leave that for another post.
The heavy use of AJAX made me introduce AJAXpro to this application. AJAXpro allows you to bring server side classes with public fields to the client, the class now becomes a javascript object with properties which you can set and pass the object back to the server. Using AJAXpro I was able to bring the "User" object to the client, populate the textfields, allow the user to change the fields, repopulate the "User" javascript object and finally pass the "User" object back to the server for a database update.
Some other fundamental refactoring methods included: renaming variables to more descriptive variable names,encapsulate fields and breaking up never ending functions. Making the code more readable by breaking statements such as this one:

try { } catch(Exception Exception){} finally{};

to
try
{

}
catch (Exception Ex)
{


}
finally
{

}
Maybe it's just me but I find it much easier and much easier to read code statements from top to bottom instead of left to right.

This post was in no way intended to criticize the style of coding or practices used by the previous developer. Developers often have time constraints that don't allow for the proper design up front and a hacky simple solution had to get it out the door by the end of the week.

Implicit typing

C#3 makes the compiler do more by implicity inferring the types of local variables. Note this is not breaking the nature of the type system, the type system is still static and type safe.

Example of inferring types:

var stringName = "hello";

//The type of stringName is System.String
//Therefore
stringName = 0; //Throws an exception.

Restrictions:

■ The variable being declared is a local variable.
■ The variable is initialized as part of the declaration.
■ The initialization expression isn’t a method group or anonymous function1
(without casting).
■ The initialization expression isn’t null.
■ Only one variable is declared in the statement.
■ The type you want the variable to have is the compile-time type of the initialization
expression.
Ref: C# IN DEPTH by Jon Skeet

MYTH #1: “REFERENCE TYPES LIVE ON THE HEAP, VALUE TYPES LIVE ON THE STACK”

I'm currently reading C# IN DEPTH by Jon Skeet great read for someone moving from C# 2 to C# 3. Jon Skeet does an excellent job using examples to take you through the evolution of C#. In his core foundations part Jon tackles some of these myths which are floating around the internet and explains the truth behind them.

MYTH #1: “REFERENCE TYPES LIVE ON THE HEAP, VALUE TYPES LIVE ON THE STACK”

Obviously not true, but some time ago during an interview I blurted out the exact same words, without thinking about it, just because it sticks in your head.

At least the the first part is true "Reference types live on the heap".
"A variable’s value lives wherever it’s declared—so if you have a class with an instance variable of type int, that variable’s value for any given object will always be where the rest of the data for the object is—on the heap. Only local variables (variables declared within methods) and method parameters live on the stack. " Ref: C# IN DEPTH by Jon Skeet

jQuery Plugins

Some great plugins for jQuery to use with ASP.NET web page.
http://encosia.com/2008/10/19/7-of-my-favorite-jquery-plugins-for-use-with-aspnet/

"params" Keyword

"The params keyword allows you to pass in a variable number of parameters without necessarily explicitly creating the array." Programming C# 2005 Jesse Liberty
Example:
DisplayVals("5", "6", "7", "8","9");//no explicitly creating the array
string[] expArray = new string[] { "1"," 2"," 3" };
DisplayVals(expArray);//passing in an explicitly created array

public void DisplayVals(params string[] intVals)
{
foreach (string i in intVals)
{
Console.WriteLine("DisplayVals {0} ", i);
}
}

Interview Question 12: When are objects destroyed? Heap vs. Stack?

"Objects on the stack are destroyed when they go out of scope. Typically a stack frame is defined by a function. Thus, if you declare a local variable within a function, the objects you place on the stack within that function will be destroyed when the function ends.
Objects on the heap are garbage-collected sometime after the final reference to them is destroyed."

Reference: Jesse Liberty Programming C# 2005

Interview Question 11: Intrinsic types vs. user-defined types?

Intrinsic types are the built-in types , int,String, float..)

User defined types are classes, enums, structs

All the intrinsic types are value types except for Object and String.

All user-defined types are reference types except for structs and enumerated types.