Wednesday, October 20, 2010

LINQ code to edit vs insert new records

Another post in the series: Things other developers do that drive me crazy

Here's an example of someone else's code that I'm currently working with:

PRODUCTGROUP AddProductGroup;

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
}
else
AddProductGroup = ProductManager.GetProductGroupByID(Convert.ToInt32(ddlProductGroups.SelectedValue));

AddProductGroup.DateModified = DateTime.Now;
AddProductGroup.LastUpdatedBy = UserProfile.GetUserGuid(User.Identity.Name);
AddProductGroup.ProductGroupName = txtProductGroupName.Text;

if(ddlProductGroups.SelectedValue == "0") Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);
Data.CurrentContext.SubmitChanges();

ProductGroupID = AddProductGroup.ProductGroupID;

Ok it's not terrible. But there is one line that seriously bugs me. It's this one:

if(ddlProductGroups.SelectedValue == "0") Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);

This code is written to handle new records being inserted and existing records being updated based on what is selected in the drop down list ddlProductGroups. Why do we need to check if the ddlProductGroups.SelectedValue is "0"? In the beginning of the code block there is already this:

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
}

So just change it to this:

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);
}


There, now you don't need that subsequent "if" statement. You can instance a new PRODUCTGROUP object, set the date created, and tell LINQ to InsertOnSubmit all in the same block of code.

Saturday, October 16, 2010

Customer Relationship Management Software

Just launched a new website for Customer Relationship Management (CRM). We build custom CRM software for companies in any industry.

Customer Relationship Management Software

Monday, August 9, 2010

Limit use of member variables in code-behind

I frequently come across code that looks something like this:

private int memberVariable;

private void StartHere() {
memberVariable=1;
}

private void RunFirst() {
memberVariable=2;
}

private void PrintResult() {
int result = memberVariable*4; //<--error on this line for example
}

Let's say there is an error on the line marked with the comment above. In troubleshooting the issue, it might be helpful to know what the value of memberVariable is. If I look at PrintResult(), I see a variable named "result" which is being defined as an int. But then I see it using "memberVariable" which is defined outside of PrintResult(). Since I didn't write this code, it is difficult for me to know what exactly memberVariable is at the time PrintResult() gets called. Did StartHere() get called before PrintResult()? Did RunFirst() get called? If both were called, which ran last?

It is much more desirable NOT to declare variables outside of the methods they are being used in. Of course there are some situations where you must do this kind of thing, but for the most part, you should be able to use variables inside methods by PASSING them to the method instead of relying on them being instanced and valued at some point before our method being called.