1. Make sure stand up meetings don't go beyond 15 min of time.
2. Never discuss a topic too deep. Say a person is facing issue in establishing an ADO.NET connection to the DB. It should remain as a hindrance issue and not a topic to discuss on.
3. Carry a piece of object like an identifier, that indicates who is speaking.
4. More importantly, don't leave the issue reported in step(2) in the stand-up but discuss it and help resolve the person his/her issue at their desk.

Stay tuned, stay healthy, keep coding!!!

Hi guys,
Wish you and your dear one's a wonderful new year- 2014 ahead.

Continuing our abilities in trying to bring the best of us using our code, we are in the 3rd episode of this. This time around, we will discuss how we can make our code get rid of the red lines.
Red lines? Yes, the hard coded text in C# is in general in red color and so we call it the Red-Color-Phobia.

Red-Color-Phobia.

Many developers have this tendency of hard coding few values, during the process of assigning things, comparing things or while retrieving things.

Example 1:
Say, there is a requirement for an online shopping portal where in, based on the current location of the active customer, a surprise discount percentage has to be offered during the Thanks Giving time.

The developer/ programmer has written this to achieve the requirement.

Var cutomerSurpriseDiscountPercentage=0; Var customerLocation = string.Empty; If(customerLocation == “New York”) {        cutomerSurpriseDiscountPercentage = 10; }

How can we better this code?

Define an ENUM that holds the names of the locations to which the surprise discount s available

enum ValidSurpriseDiscountLocations{ NewYork = “New York”, Detroit, NewJersy = “New Jersy” }

Thus, our code is little modified for a better quality

Var cutomerSurpriseDiscountPercentage=0; Var customerLocation = string.Empty; If(customerLocation == ValidSurpriseDiscountLocations. NewYork) {        cutomerSurpriseDiscountPercentage = 10; }

See you again.

In our previous post episode -1, we spoke on how we can make our variable names can talk and all of them put together can tell their story on their own.

But if we see, in our previous code snippet, we can improve it much more than what it is now. Lets go get it here...

var customersBilledThisMonth; //fill the list here for(int currentCustomerNode=0; currentCustomerNode<customersBilledThisMonth.count;                   currentCustomerNode++) {         if(customersBilledThisMonth[currentCustomerNode].billedAmount>750)        {              Console.WriteLine(customersBilledThisMonth[currentCustomerNode].customerName);         } }

We can see a number in the code, right? Hey, what is this? Have a look at it a little closely...

Yeah!! I get it. It says if the value billedAmount is greater than 750, we enter the IF-condition. 

Okay, now let us make our code better. Let it talk to us on its own.

var customersBilledThisMonth; //fill the list here var currentMonthTotalBillAmount = 750; for(int currentCustomerNode=0; currentCustomerNode<customersBilledThisMonth.count;            currentCustomerNode++) {         if(customersBilledThisMonth[currentCustomerNode].billedAmount> currentMonthTotalBillAmount)        {              Console.WriteLine(customersBilledThisMonth[currentCustomerNode].customerName);         } }

That's it? Not really.
Lets make it little more readable and story telling thing. What if the client want this value to be changed to $900 next month? Open the project, change the code, build and deploy again? NO. So what we do is make it configurable.

Add the below code in config.cs

<appSettings> <add key ="currentBillingAmount" value = "750"/> </appSettings>

change the value assigned to the variable as below

var currentMonthTotalBillAmount = ConfigurationSettings.AppSettings("currentBillingAmount");

Now, add the string that's hard coded into an enum file or a constants file, so that if the name spelled at different areas stay the same and there are no typos.

Observed the change? Now its more easy to understand what the code is doing?

There are many more ways than just this. This is one way of making our code do the right thing than just deliver the mere functionality.

 Yes, its telling its story. Will talk more in the next episode.

Whaaattt......how can a code talk? Its Okay. Don't get too confused. Lets jump in....
Everyday, we spend most of our time writing the best that we believe is good for the project that we work on. At the end of the day, it should not just remain like - do some work on a button click or change content of the page based on a drop-down.

The code behind the application should tell you as a developer what it is doing.

example:
Requirement: There is a list that holds the customers for a company who have billed the highest for the current month. We should loop through the list and print the names of the customers in the list whose billing amount is greater than $750.

Code:

var custLst;

//fill the list here

for(int i=0;i<custLst;i++)
{
        if(custLst[i].BildAmt>750)
       {

             Console.WriteLine(custLst[i].Name);

        }
}

as you can read through, we will understand that it prints the name onto the console pane for the condition where the billing amount is greater than $750 by looping through the list. LIST..."i"......!!!

So whats the great deal????......... just think again... is the code really conveying the same as what we talked as above??? ......... NOT REALLY.....RIGHT???

now we will tweak the above same code to make it talk and tell its story on its own.... yes code should tell what it is doing and its story....


var customersBilledThisMonth;

//fill the list here

for(int currentCustomerNode=0; currentCustomerNode<customersBilledThisMonth; currentCustomerNode++)

{

        if(customersBilledThisMonth[currentCustomerNode].billedAmount>750)

       {

             Console.WriteLine(customersBilledThisMonth[currentCustomerNode].customerName);

        }

}

the above code makes more sense, isn't it?
We will talk more about  - Lets make our code talk in the next post