JohnnyCoder » Best Practices

Managing .NET External Dependencies

Ben Griswold — Mon, 22 Mar 2010 21:19:01 +0000

Noah and I continue our screencast series by sharing our approach to managing external dependencies referenced within a .NET solution. This is another introductory episode but you might find a hidden gem in the short 4-minute clip.

ELMAH (Error Logging Modules and Handlers) is the external dependencies we are focusing on in the presentation. If you are not familiar with ELMAH, this episode may be worth your time.

YouTube
- Managing .NET External Dependencies

This is one of our first screencasts. If you have feedback, I’d love to hear it.

Visual Studio 2008 Solution Setup

Ben Griswold — Mon, 15 Mar 2010 15:23:09 +0000

In this screencast, Noah and I demonstrate preferred practices around .NET solution setup, naming conventions and version control. I consider this an introductory video. If you’ve been around the block, you might want to skip this episode but if you’re a .NET/Visual Studio newbie, it may be worth a look.

YouTube
- Visual Studio 2008 Solution Setup

This is one of our first screencasts. Actually it is the very first. If you have feedback, I’d love to hear it.

HTTPHandler with JSON Data

Ben Griswold — Tue, 16 Dec 2008 17:24:17 +0000

As javascript libraries, particularly jQuery, increase in popularity so do web techniques using AJAX and JSON.

Have you ever seen this code? It is front and back of an ASPX file with the single responsibility to return JSON data per an AJAX request.

GetDataPage.aspx

<%@ Page Language="C#" AutoEventWireup="true"
    CodeFile="GetDataPage.aspx.cs" Inherits="GetDataPage" %>
<%--
    This minimal code is here to prevent the following error:
     "Using themed css files requires a header control on the page"
     Please see http://www.west-wind.com/WebLog/posts/4662.aspx
     for more information --%>
<head id="Head1" runat="server" visible="false" />

GetDataPage.aspx.cs

using System;
using System.Web;
using System.Text;

public partial class GetDataPage : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Clear out the buffer
        Response.ClearHeaders();
        Response.ClearContent();
        Response.Clear();

        // Do not cache response
        Response.Cache.SetCacheability(HttpCacheability.NoCache);

        // Set the content type and encoding for JSON
        Response.ContentType = "application/json";
        Response.ContentEncoding = Encoding.UTF8;

        int page = int.Parse(Request["p"]);
        string results = DataAccess.GetResults(page);

        Response.Write(results);

        // Flush the response buffer
        Response.Flush();

        // Complete the request.  NOTE: Do not use Response.End() here,
        // because it throws a ThreadAbortException, which cannot be caught!
        HttpContext.Current.ApplicationInstance.CompleteRequest();
    }
}

You may have noticed there’s a comment for nearly every code block. At first, one may find the comments redundant and unnecessary, but really they are call for help. A code:comment ratio like this usually indicates you really need to focus on what’s happening with the code because if you aren’t paying attention, bad things might happen.

As you have undoubtedly concluded, there’s a lot of overhead associated with returning JSON data from an ASPX file. This statement is especially true if you consider the alternative, an HTTPHandler. Here’s a cleaner, best-practices approach which provides the same outcome with less code, comments and risk.

GetDataHandler.ashx

<%@ WebHandler Language="C#" Class="GetDataHandler" %>

using System.Text;
using System.Web;

public class GetDataHandler : IHttpHandler
{
    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest (HttpContext context)
    {
        context.Response.ContentType = "application/json";
        context.Response.ContentEncoding = Encoding.UTF8;

        int page = int.Parse(context.Request["p"]);
        string results = DataAccess.GetResults(page);

        context.Response.Write(results);
    }
}

If you are already accustomed to using generic handlers to stream back images, XML, JSON data, etc, this post was probably a bore. But it’s sometimes easy to forget what’s available to you in the vast .NET stack, so hopefully you appreciate the friendly reminder. In either case, it still surprises me how many examples use the ASPX approach. In fact, the practice is common enough that I sometimes wonder if there’s an HTTPHandler gotcha to which I’m not privy . If I am missing something, please let me know.

If you’re still interested, attached you’ll find code which populates two jQuery Flexbox controls using JSON data provided through an ASPX and ASHX files. This may be worthwhile download if you’re interest in the generic handler code or you want a further look at Flexbox in action after last week’s post.

Download JsonHandler Sample Project: JsonHandler.zip

Guarding Against Multiple Empty Strings

Ben Griswold — Thu, 13 Nov 2008 06:08:42 +0000

Many of my C# methods include what is referred to as a guard clause. It isn’t a complicated concept. Simply the first few statements of a routine validates passed-in parameters and/or state of the object and immediately returns an error or gracefully exits to the function is constraints aren’t met. If I’m not mistaken, this plays nicely with the Design by Contract approach to software design, but I no expect on the subject. The bottom line is, a guard clause can really tighten and clean up your code because it will undoubtedly eliminate any number of nested conditional statements.

Consider the following sample taken directly from c2.com:

public Foo merge(Foo a, Foo b)
{
    Foo result;
    if (a != null)
    {
        if (b != null)
        {
            // complicated merge code goes here.
        }
        else
        {
            result = a;
        }
    }
    else
    {
        result = b;
    }
    return result;
}

Now with the guard clause…

public Foo merge(Foo a, Foo b)
{
    if (a == null) return b;
    if (b == null) return a;
    // complicated merge code goes here.
}

Much cleaner, eh? And that’s only two conditionals! Back to my point. Many of my method include guard clauses. Today I needed to validate that all three string parameters had a value. In other words, each string’s length was greater than 0.

I started with my faithful Is-Not-Null-Or-Empty check:

string a = "a";
string b = "b";
string c = "";

if (string.IsNullOrEmpty(a) ||
    string.IsNullOrEmpty(b) ||
    string.IsNullOrEmpty(c))
    return;

But then I settled on this:

string a = "a";
string b = "b";
string c = "";

if (a.Length * b.Length * c.Length == 0) return;

What do you think? Pretty hokey, right?

I Am Not A Control Developer

Ben Griswold — Wed, 15 Oct 2008 04:50:20 +0000

I’ve created a number of user and server controls for my C# web applications. Recently, however, I’ve found myself working in Silverlight and, if you are of the same opinion as me, you believe Silverlight was missing a few core controls. Specifically, Silverlight was missing a TextBox with password masking and a CombBox until Monday’s Silverlight 2 Release Announcement. Prior to the release candidate becoming available a couple of weeks ago, you had 3 options if you needed one of these controls in your Silverlight application; you could purchase a commercial control, find an open source implementation or hack your own control together.

I really didn’t know enough to put together my own solution so I downloaded a lot of code and clicked through numerous demos in an attempt to find something that already worked. Luckily, I found sample code available for a PasswordTextbox which needed little fine tuning on Chris Pietshcmann’s blog. Though I literally searched for hours and sampled many implementations, I didn’t find a satisfactory commercial or open source ComboBox control. Ultimately, I settled on a AutoComplete TextBox / ComboBox hybrid which I pieced together with the help of a couple of posts made by Ary Borenszweig. I was really encouraged but how much I learned through the process and even though my controls will have an exceptionally short life expectancy, I am pleased with how they turned out.

I found it interesting to discover that only a few of the controls I researched/tested really, really worked. Yes, primary functionality was in place the majority of the time, but shortcomings became obvious once I dropped the controls into a “real” application. So, here are a few thoughts I collected for those (including myself) interested in pursuing control development:

Code for both the mouse and the keyboard user. Think big strokes like navigation, data entry and value selection. Whatever action is available via the mouse should be available via the keyboard and vice versa. For example, don’t make users click on the ComboBox in order to have the dropdown list appear. Instead, get familiar with standard ComboBox operations by playing with ComboBoxes found in other frameworks. Comboboxes have been around for a long time. Unless you mimic de facto standard functionality, your control will be full of holes.

Don’t forget to test the edge cases. Sure. Most of the time a user is going to simply enter a password from left to right, one character at a time, but what if the user copy and pastes in an entire password or, better yet, what if a password is entered and then the user selects and replaces the middle three characters without ever touching the mouse. Here’s a good one: what happens if the PasswordTextBox mask, perhaps an asterisks, is entered as part of the password string? Will your control break? I am pretty sure mine will… Edge cases are tricky and endless. The main point here is test, test, test anything a user might do.

Test controls in a real world scenario. There’s a lot you can immediately learn about a control once you start using it with purpose. Is your control easily populated? Can you easily extract the value? Can the control be validated? If necessary, how does the invalid state present itself? When it comes to look and feel, can your control use existing themes/styles? Finally, does your control play nicely with others? Can you tab in and out of your control smoothly? Can you programmatically give focus to your control? What happens when your control loses focus? Until you drop your control into an application, some of those questions may not be considered or answerable.

Again, I am not a control developer, but I will keep the thoughts above in mind the next time I create a control. Happy coding.

VS2008 Test Project Tips

Ben Griswold — Mon, 04 Aug 2008 13:00:00 +0000

As I mentioned last week, I am new to TDD. For better or worse, all of my tests (and spikes) have been generated via Visual Studio Test Projects. Working with VS Test Projects hasn’t been all that bad although I noticed a couple of annoyances right away.

Is anyone else bothered by the fact that, by default, an unlimited number of test results and binaries are “deployed?” If you are testing first, this arguably makes for a lot of useless activity and waste disk space. Since the default TestResults folder location is set to be side-by-side with your solution files, the extra folders, trx files and binaries can also really interfere with your otherwise easy source control check-ins.

Fortunately, there are ways to work around the excessive TestResults problem if you are running VS2008. Some options are available through the IDE and other require an update to the .testrunconfig file directly:

Limit the number of deployed tests:

Tools > Options > Test Tools > Test Execution > Test Results Management > Limit number of old Test Results to the value of your choosing.

The screen shot below sets the number of tests to one. Therefore all previous tests are purged and only the latest test is maintained.

Disable Test Result deployment:

If you wish to disable the Test Result generation completely, double-click on your solution’s .testrunconfig file and uncheck the “Enable deployment” option. No results will be generated thereafter.

Change the Test Result folder location:

This option is hidden. I don’t believe it is exposed in any of the VS 2008 dialogues and you have to edit the .testrunconfig file directly.

Right-click on the .testrunconfig file > Open With… > XML Editor > Include the following within the TestRunConfiguration node:

<Deployment useDefaultDeploymentRoot="false" userDeploymentRoot="C:\TestResults" />

I hope it helps.

References:

Safe Cast for No Good Reason

Ben Griswold — Wed, 11 Jun 2008 03:17:15 +0000

I’m not sure I can come up with a good argument to ever use Safe Casting. Per my earlier post, I’m not able to convert the result of the following Predicate, List, to a MachineProductCollection even though MachineProductCollection inherits from List.

// Code complies and the invalid Cast results in
// machineProducts being set to null instead of an
// exception being thrown.
MachineProductCollection machineProducts =
    MachineProductList.FindAll(c => c.MachineID == MachineID)
    as MachineProductCollection;

As statement in the above comment, the invalid cast is essentially masked due to the Safe Cast or the convert using the “as” operator. Alternative implementations, I believe, are more appropriate as an implicit conversion causes a pre-runtime, compilation error and a “traditional” cast throws an InvalidCastException at runtime, respectively:

// Compiler complains since it knows List can not
// be converted to MachineProductCollection
MachineProductCollection machineProducts =
        MachineProductList.FindAll(c => c.MachineID == MachineID);

// Code compiles but a runtime InvalidCastException is thrown
// since List can not be converted to
// MachineProductCollection
MachineProductCollection machineProducts = (MachineProductCollection)
        MachineProductList.FindAll(c => c.MachineID == MachineID);

I’m probably missing something but I can’t think of a scenario in which I would intentionally want to assign a null value if my cast is invalid. Why “swallow” the exception and work with bad data? It doesn’t make sense to me.

I’ve read that one should use the “is” operator in conjunction with the “as” operator. Basically, this ensures the conversion is valid before it is executed, but what is the point. Do more work to get the same lousy, invalid result?

// What is the point of this?
MachineProductCollection machineProducts = null;

if (MachineProductList.FindAll(c =>
    c.MachineID == MachineID) is MachineProductCollection)
{
    machineProducts = MachineProductList.FindAll(c => c.MachineID == MachineID)
        as MachineProductCollection;
}

Perhaps I should have taken more CS classes in college…

Additional References:

Safe Conversion of Reference Types

SQL Tip: Uniquely Name Table Columns

Ben Griswold — Tue, 10 Jun 2008 23:43:58 +0000

It is easy to see the subtle difference between the Product Tables below. The table to the left adds the table name as a prefix to nearly all of the column names. The table on the right represents very simple column names with no redundancy. Early in my career, I preferred the implementation to the right as I felt this pattern best represented the object (table) itself. After all, we all have a name. We don’t have a PersonName. Well, it didn’t take me long to change my opinion.

The next time you are designing a database, do yourself a favor and mimic the pattern to the left. Always prefix column names with the table name if the column name is likely to be repeated in more than one table. ID, Name, Description, DateAdd and DateChange are good examples of column names which tend to show up in multiple places. When it comes time to build your queries and work with the result sets, you will thank me.

Consider the two following routines — each returns the same result but the latter is much cleaner, readable, consists of less code and is inherently greater resistant to stupid coding errors especially within the syntax of the join and the column aliases.

-- Poor implementation
declare @Product table
(
    ID int, Name varchar(50)
)

declare @ProductVersion table
(
    ID int, ProductID int, VersionNumber int
)

insert into @Product(ID, Name)
select 1, 'product 1'
union
select 2, 'product 2'

insert into @ProductVersion (ID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

-- Note the column aliases and
-- join on less-than-obvious columns
select P.ID as ProductID, PV.ID as ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ID = PV.ProductID)

go

-- Proper implementation
declare @Product table
(
    ProductID int, Name varchar(50)
)

declare @ProductVersion table
(
    ProductVersionID int, ProductID int, VersionNumber int
)

insert into @Product(ProductID, Name)
select 1, 'product 1'
union
select 2, 'product 2'

insert into @ProductVersion (ProductVersionID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

-- Note there's no need for aliases and
-- the join obvious
select P.ProductID, PV.ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ProductID = PV.ProductID)

Keep this tip in mind. It will save you heartache throughout your next project.

CAPTCHA Roulette

Ben Griswold — Tue, 10 Jun 2008 22:39:48 +0000

I vividly recall creating my Windows Live account and wondering how many folks are able to guess the 8 character CAPTCHA on the first attempt. I swear the CAPTCHA presented to me looked like random scribbles in a box. I did take screen shots but they seemed to have disappeared just like my patience on the day of signup.

Yesterday, I revisited the page and came up with the following examples. I don’t think these samples are THAT bad, but can you decipher any of characters strings with 100% confidence? I doubt anyone can and I think this feat is well-known to be impossible.

Have a look at all the help one gets. For one, the “8 character” hint helps a lot. And if you are still stumped, a new CAPTCHA can be requested until one becomes answerable. And if that fails, take a whack at the audio version in order to validate being human.

Coding Horror had a nice write up on CAPTCHA Effectiveness a while back. The claim was that even the most basic, most ineffective form of CAPTCHA, “naive CAPTCHA” where the CAPTCHA term is the same every single time, stops 99.9% of content span.

Granted, these statements were written before Coding Horror had 103K subscribers. I suspect this was well before Coding Horror needed to be overly concerned with telling computers and humans apart, but I think the sentiment that CAPTCHA doesn’t need to overly inconvenience the user to be highly effective still applies.

I am not opposed to extreme CAPTCHA — especially when hints are provided — but the extra clicks and guesses bugs me enough to go into a useless rant about Y’s, I’s and J’s…

Code Generation with Stored Procedures?

Ben Griswold — Mon, 02 Jun 2008 20:49:40 +0000

I very recently posted about using SubSonic to generate my DAL and SSMS Tool Pack to generate the complementing stored procedures. In response to the post, Jon Galloway asked a great question in the comments:

Thanks for the pointer to SSMS Tool Packs. It looks really interesting. One thing I’m having trouble picturing is the overlap between the two [SubSonic and SSMS Tool Pack]. Once you have a DAL, what do you need CRUD routines for? Bulk operations, or something that’s a result of the existing architecture?

For those familiar with SubSonic you can appreciate Jon’s question. Since SubSonic’s generated DAL provides you with CRUD methods and easily allows you build resulting parameterized queries, you are no longer dependent upon having compiled routines sitting in the database.

Almost on queue, Caffeinated Coder recently a great article on why one should “Just Say No to Manual CRUD” which provide a list of resources which present good counter arguments against the conventional stored proc wisdom.

So, why the heck am I still using stored procedures?

If I were to be honest, the number one reason I’m sticking with SPs is they are familiar and they provide me with a sense of comfort. Most of my uneasiness with “embedding” data access into the application code is tied to deployment and maintenance. For example, I like to have multiple “outs” when it comes to rollbacks and I like to keep emergency fixes as isolated as possible. Since stored procedures could be considered more atomic than even the most lightweight DLL, I can update a live application by altering a single stored procedure with more confidence than copying/replacing application file(s.) Assuming you have a single database and a web application running on multiple web servers, in my opinion, the stored procedure update is best solution since time to implement is low, risk is minimal and downtime is eliminated.

I had a good follow up conversation with Jon about all of this last week and the bottom-line is that one needs to put the right architecture in place based on their coding, deployment and maintenance needs. I am currently sticking with stored procedures but this approach isn’t necessarily right for everyone.

Multiple Web Sites with Host Headers?

Ben Griswold — Sat, 24 May 2008 14:41:17 +0000

I woke up this morning (whew) wondering what percentage of the development community is privileged enough to deploy their own stuff. I wonder because I think I’m out of touch in this area. Over the past 6 or so years I’ve been handing off installation/deployment duties to other groups. My development teams and I were very involved in the release of our applications — sometimes to the point of executing the installation ourselves — but 95% of the time the actual server/network setup fell outside of our responsibility. With my new position, things are very different. Now, I’m pretty much responsible for everything and anything.

Last week, I setup a new web site. This task included everything from registering the domain to getting the various instances of the site (for example, dev.site.com and qa.site.com) mapped to different IPs. It was a “fun” exercise as it’s been forever since I needed to do this sort of thing. In fact, it didn’t go super-smoothly the first time around as the host company didn’t apply the IP mapping appropriately. Anyhow, I shared my woes with the former colleague and their response was something along the lines of “you know so much more about that stuff than I do.”

As it turns out, it was the Host Header Names reference which threw my colleague. If you are in the same boat, Microsoft Internet Information Services (IIS) allows you to map multiple web sites with the same port number to a single IP address by using a feature called Host Header Names. By assigning a unique host header name to each web site, this feature allows you to map more than one web site to an IP address. Knowing about Host Header Names can come in handy — especially if someone else isn’t always going to be doing your dirty work.

Back to my point: I was still a bit surprised by my buddy’s response, but then I thought it through. In order to develop a .NET web site, one doesn’t even need to open IIS. Not ever. Not since 2.0 at least. And once the basic setup (domain registering, DNS entries, IIS configuration) is in place on the destination server, a .NET web site can be deployed through a mere file copy. If you aren’t involved in the initial setup/install, a developer doesn’t need to know how to do anything other than how to code and copy files in order to maintain/enhance a live site. Is it possible that a developer can get along perfectly well without having to know anything about web site deployment?

Hide Troubleshooting Info In The App Footer

Ben Griswold — Sun, 10 Feb 2008 04:35:03 +0000

Whenever I can get away with it, I include basic troubleshooting information in the footer of my web applications. So it isn’t distracting (or blatantly exposed) to the standard user, the text is hidden. In other words, I make the font color the same as the background color so the text is only visible when selected.

The hidden text is intended to give the developer basic information about the logged-in user, server and build as well as enough information to link the user’s session back to more detailed logs.

So, prior to a release to the Test Environment, I share the location of the hidden text with the QA and UAT groups and request they include the information when writing up defects. And once the application rolls to the Production Environment, the Help Desk and Stability Groups begin to leverage the information as well.

Even though the information is “hidden,” I am very particular/careful when it comes to the troubleshooting information which I present. As a general rule, I only include information which would be harmless if “found” by anyone — including future auditors. I use this technique with caution, but I do use it whenever I can. I’ve found this “trick” very handy over the years and maybe now you will too.

Do you have any troubleshooting tips which can be shared?

Don’t Mix DDL and DML

Ben Griswold — Wed, 06 Feb 2008 03:16:28 +0000

I sat through an absolutely fantastic presentation on query optimization a couple of weeks back. The presenter did a fine job of covering many of the basics like SET NOCOUNT ON, minimize cursor use, avoid explicit or implicit functions in the WHERE clause and why not to use the sp_ prefix when naming custom stored procedures. He also touched upon practices which are critical aspects of query optimization, yet, in my opinion, few put into practice. Specifically, he talked about the need for benchmarks and how to establish them. He also demonstrated how to conduct sufficient testing. Then there were the more advanced topics like table fragmentation, associated DBCC commands, Statistics IO, Fill Factor and how procedure cache works. He also shared plenty of TSQL samples and how they will (or will not) use a given index. For example, did you know the LIKE clause can use indexes if the pattern starts with a character string such as WHERE lname LIKE ‘W%’ but LIKE cannot use an index if the pattern starts with a leading wildcard, such as WHERE lname LIKE ‘%wold’? Again, excellent presentation and did I mention it was wrapped up in under an hour?

I typically roll the dice with these types of presentation knowing they may turn out to be a refresher course, way over my head, or worse, an absolute bore. This one was worth sitting through as I picked up the following nugget: Mixing DDL and DML Operations Can Cause a Recompile.

What does this mean? DDL (Data Definition Language) and DML (Data Manipulation Language) almost always exists in our stored procedures. Examples of DDL are our DECLARE variable and CREATE TABLE statements. DML, on the other hand, includes our SET, SELECT and INSERT to name a few. A key cause of stored procedure recompiles is the interleaving of DML and DDL statements — especially DDL following DML statements. In other words, according to Microsoft best practices, place all of your DDL statements at the top of your stored procedures and then do your actual query work. Now, are recompiles always going to happen if you have interleaved DDL and DML? Nope, not in all case, but you should do everything possible to prevent recompiles (even if it is super easy.)

Rolling Back Refactored Code

Ben Griswold — Thu, 14 Dec 2006 17:21:27 +0000

My current project has me exercising a number of financial formulas on security and benchmark data. I have 2 – 3 sets of data which based on their type (benchmark or not) have varying calculations which set similar properties. I won’t bore you with the details, but the calculations do require more than the four basic math operators. In addition, the sets are dependent upon each other. For example, a start date common to each set needs to be determined and, in cases, benchmark results are leveraged in non-benchmark sets.

Along with a test application, I’m going to be handing my code off to other developers and I really want the transition to be as seamless as possible. To help out with this, I have spent some time creating my component in an intelligent, easy-to-use manner. (What? I don’t always do this?) For example, I’ve opted to have my component simply accept whatever raw data is available. The component will “clean” the data, determine the number of sets and types and process. Most importantly, the results will then provided back using datatypes which I think are most suitable for consumption by the calling application.

I like the current architecture, but I had reservations with the way the calculations were coded. As it turns out, a few of the calculations require the exact same logic. For example, Formula A and Formula B might each loop through the last 10 years of quarterly return data. Obviously, this had me wanting to combine some of my routines. But as I refactored and refactored and refactored, I found my code was getting more and more and more obscure. The logic was very difficult to understand (never mind read) and I wasn’t comfortable handing it off to others.

I’ve rolled back my refactored code. I’ve blatantly abandoned refactoring in this case. Instead, I’m keeping the code in logical blocks which I believe will aid in learning, extending and (gasp!) troubleshooting the component in the future. Though I’m sure there would have been performance gains if I were to continue down the refactoring path, I’ve convinced myself that they would be subtle. Perhaps I could have added ample (read: lots and lots) comments to accompany the obscure, refactored code, but I don’t think good code requires such measures.

I’m happy with my decision. Now it’s time to finish up, hand off the code and wait for the new owners to laugh at its poor quality — of which they will hopefully understand and be able to manage every line. We’ll see.

I should mention, I will be reworking some of my code. Do yourself a favor. If you know you are going to be performing anything other than basic math, don’t use decimals. Use doubles instead. Thanks to functions like Math.Pow() and Math.Sqrt(), I’ve been casting my brains out over the past couple of days and it is time I bite the bullet and change my datatypes.

Over 2,147,483,648 Users Served

Ben Griswold — Sun, 19 Nov 2006 17:56:59 +0000

Not so long ago, one of our applications failed when we tried to handle the 32,768th user entry. Though the database was able to manage the request, the application held onto the row’s identity in an Int16 property. The overwhelming response to the error was “That was really, really dumb.”

I tend to agree on a couple of accounts. First and foremost, capacity/growth requirements should have been better measured (especially since the coders decided to go out of their way to use a data type other than the de facto standard Int32.) Second, complementary data types should have been used in SQL Server and the C# code.

Understandably, the coders were embarrassed, but the problem was quickly remedied with very little damage done.

Possibly triggered by a recent article I read, this morning I got to thinking, “What if it wasn’t an Int16? What if the system failed because the coders were only using an Int32?” I have to think that any acknowledgement that your application has handled over a two billion entries would be welcome — even if it comes in the form of a system failure.

How’s that for looking at the bright side?

Coding Standards – The Devil Is In The Details

Ben Griswold — Fri, 03 Nov 2006 19:55:30 +0000

A couple of years back, I was tasked with compiling C# coding standards for our development department. To be honest, I wasn’t all that excited about the assignment. Previous attempts had been met with quite a bit of resistance and worthless debate and I wasn’t sure I really wanted to open that can of worms again. After all, I felt that we had built a talented team of developers who saw eye-to-eye on most “technical things” so why bother getting everyone riled up? As you know, there are many legitimate reasons for “getting everyone riled up.” In our case, there were two very good reasons which made my assignment somewhat mandatory:

We had plans to greatly expand the size of our group in the very near future and documented standards would help get the newbies up-to-speed quickly.
Our group’s technical roadmap was becoming more defined (heck, it was taking a turn with SOA) and there were embracing a number of technical advances such as .NET 2.0, Remoting and AJAX and we needed to ensure the existing staff on the same page.

Ultimately, I accepted the challenge and standards were put in place with very little blood shed. Of course, I took a few measure to ensure that mud-slinging and stone-throwing was kept to a minimum.First, I anticipated the pain and I didn’t let it happen. To accomplish this, I guess I was a bit evasive. I didn’t solicit any help or opinions at first. I did endless online searches and I consulted a few books, but I avoided internal roundtable discussions. I also decided to wait until the documentation was rather polished before requesting any feedback. Once I did seek feedback, I kept participant counts low. In fact, only a handful of our technical leaders were invited to the review before distributing before the document was distributed to the entire development group.

Second, it was established early on that there would be difference of opinion and this was okay. Actually, it was almost encouraged, but we all (non-verbally) agreed to keep our egos out of the debate. This ultimately lead to us coming to a common ground or simply opting to “choose our battles” and accept that we wouldn’t always get what we wanted. This, in conjunction with everyone knowing their feedback was valued and respected, kept our conversations on track. Also if a topic got at all heated, we quickly moved onto something else in an effort to stay focused, to keep moving forward and keep everyone happy.

Most importantly, however, we didn’t sweat the small stuff. If you have been responsible for documenting agreed upon standards, you know what I’m talking about. Developers tend to spend just as much time hashing out the small stuff as they do the big stuff. When it comes to establishing your team’s coding guidelines, the devil is in the details. The classic example is code formatting. “Which case are we going to use? Camel or Pascal or both?” “Is Hungarian notation really dead because there is still a lot of merit in using it for form elements?” “Should we prefix private property names with underscores?” “We will use curly braces within our if-else statements even if the conditions are only a single line, right?” “How many spaces are we going to agree to indent? Please assure me that no one indents using spaces! Everyone better be using the Tab key!” There are about a million distracting, time-consuming, worthless arguments which one can have about code formatting (and other similar topics) but they provide little value. These debates can suck the life out of an initiative so beware.

I think I got lucky on my third point. To some extend, our development focus had been rapidly changing over the past few years and the individuals helping to define our standards were now interested in the big picture. Perhaps we felt we had “better things” to discuss or maybe we had all learned from our past and we knew the danger of “the details.” In any case, we concentrate on the big ticket items like namespacing, data access and logging. We traded in the time we would have given to meaningless debates and we put frameworks and templates in place.

Whatever your reason, it is important to have standards. Do yourself a favor. When it comes time to defining your own, avoid the details. Otherwise, prepare for a battle which nobody wins and nothing gets done.

Take Advantage of Application Name

Ben Griswold — Tue, 24 Oct 2006 07:44:21 +0000

Along with the SQL Server, Database, Username and Password, don’t forget to include the Application Name in your connection string. It’s an optional parameter, but it can be a lifesaver.

     Data Source=myServer;
     Initial Catalog=myDB;
     User Id=myUsername;
     Password=myPassword;
     Application Name=myApp;

Consider this example: There are multiple .NET applications running on a single web server. Each application shares a common SQL Server Server which is suddenly performing very poorly. You are tasked with determine which of the applications is causing havoc. You launch SQL Profiler and run a trace. Since you have included the optional parameter in your connection string, you may now filter the application specific queries and troubleshoot the problem far more effectively. If you hadn’t specified the application name, you would have some work ahead of you. In this case, all of the queries would have had a generic app name, .NET sqlClient Data Provider, and that isn’t very helpful, is it?

Do yourself a favor and be sure to add this practice to your coding standards…

Poor Performance with DateTime.Parse()

Ben Griswold — Wed, 18 Oct 2006 22:42:47 +0000

We traced a performance bottleneck to a single function recently. Interestingly enough, this function has been in existence (running in a production environment in all of its glory) for roughly 4 years now. Only now that we are required to execute the offending piece of code approximately 10 million times within a short four hour window has the problem actually surfaced.Our function has about 100 LOC. It contains custom collection class references, string manipulation, financial calculations and numerous other operations which I would flag as suspicious. We successfully avoided performance counters and simply stepped through the code after ensuring we had set an adequate number of timespan variables to track execution times the old fashion way. As it works out, DateTime.Parse we the bottleneck and our simple logic to determine is IsDate() or IsDatePast() might as well have been the most complicated, resource-eating routines on the planet.Why was this? Well, the Parse method tries very hard to make sense of the string thatâ€™s passed to it in order to create a valid DateTime value. It ignores leading and trailing white space, and unrecognized characters if possible, and it fills in missing information with the corresponding current date and time values. Parse will throw a FormatException if itâ€™s unable to decipher the string you send to it, but otherwise, it bends over backwards for you. Our guess is it tries to do too much for its own good and exhausts itself in the process.We tried to replace the Parse method with the other DateTime static method â€” ParseExact â€” but it didnâ€™t provide much relief.In the end, we got creative. We opted to create a simple function which first instantiates a new DateTime reference by using the month, day and year from the string representation of the date. (We were lucky because we knew this string would either be in the MM/DD/YYYY format or emtpy.) Would you believe that splitting our string and then constructing a new DateTime reference performed considerably better than using the standard DateTime.Parse method? Well, it did.

1: ///

2: ///Do not rely on the DateTime.Parse() method 3: ///Check if date is in the past by splitting string, 4: ///building datetime object then compare against today 5: ///

6: ///Date to Check 7: ///False if greater than today8: public static bool IsDatePastParse(string sDate) 9: { 10: try 11: { 12: if (sDate.Length > 0) 13: { 14: string[] dt = sDate.Split(‘/’); 15: return IsDatePast(16: new DateTime(Convert.ToInt32(dt[2]), 17: Convert.ToInt32(dt[0]),18: Convert.ToInt32(dt[1])));19: } 20: else 21: {22: // Invalid if no date is passed 23: return false; 24: } 25: } 26: catch 27: { 28: // Assume the string was an invalid date29: return false; 30: } 31: } 32: 33: ///

34: ///Has the date past? Compare against today’s date. 35: ///

36: ///Date to Check 37: ///False if date is in the past38: public static bool isDatePast(DateTime dtDate) 39: { 40: // Consider today in the past41: if (DateTime.Today.Date >= dtDate.Date) 42: return true; 43: else 44: return false; 45: }

Why Don’t We Handle Exceptions

Ben Griswold — Tue, 17 Oct 2006 16:59:00 +0000

Exception handling is extremely important, isn’t it? When it comes to testing, troubleshooting and maintenance it is paramount. Exception handling is definitely highlighted on every developers list of application technical requirements. So, why don’t all applications have proper exception handling? I have a few ideas.

The first and most likely reason is most developers (no matter how experienced) don’t have a good understanding of how to do it. This operation may seem trivial to some, but it actually takes a good amount of attention and care to do correctly. Granted, in many cases it’s perfectly fine to simply wrap the contents of a function with a “generic” try/catch block and merely bubble the exception up to its caller. Great. But what does the caller do with the exception? Nine out of ten times the caller, in turn, will also bubble the exception up (because that’s what the “pattern” does) or it swallows it. Even if a coder uses this bare bones approach, there are usually issues with the implementation. For example, there is a big difference between throw; and throw ex;. The difference is that throw; preserves the original stack trace and throw ex; truncates the stack trace below the method in which the throw ex; call is located. Most of the time, throw ex; is inappropriately. There are many other examples of poor exception handling, but here’s my favorite — the coder does everything “by the book” until it is time to display a error page and a coder reveals the exception details including secure information such as connection strings to the user. Yikes! Not understand proper exception handling can be dangerous.

The second reason is priority and timeline. Exception handling isn’t sexy and, let’s be honest, it doesn’t need to be in place before an application can be deployed. Hence, exception handling is usually pushed to the backburner — along with technical documentation. Only once the application requires future troubleshooting do we feel the pain of the missing “requirement.” Interesting enough, a colleague of mine now waits until his code base is quite stable to implement his error handling. He does this without regard for priority and timeline. He’d prefer to have his application assume unnecessary fatal errors early on it the project lifecycle rather than mask the issues through improper exception handling. All the same, timeline is still a standard developer excuse for lack of error handling.

The third reason is ego. Aren’t we all a little guilty of thinking our code can’t fail? After all, we can’t have a bunch of coders with defeatist-attitudes working on our projects. Without the safety net of exception handling, we are bound to write better code, right? (Of course, this argument doesn’t hold a lot of water since it would promote getting rid of the QA team if we wanted really good code.) I do think ego is a factor though, but I’m not sure to what extent.

That’s my take on exception handling. What do you think?

Improve String Management with StringBuilder

Ben Griswold — Wed, 09 Aug 2006 22:17:00 +0000

Strings are immutable. In other words, a string can not be changed once assigned. When you append a string to an existing string, the .NET framework actually creates a new string containing the original string and the appended string. This is a resource-hungry and time-consuming process.

The alternative to appending strings, is the StringBuilder class which is somewhat hidden in the System.Text namespace. The class is faster because it allocates an initial space when an instance of it is created. By default, a StringBuilder object created using the StringBuilder class default constructor reserves a space of 16 characters in memory. This default can be overloaded.

Generally, the recommended cutoff number is five. If you have more than five separate string concatenations, StringBuilder is generally more efficient than appending the strings.

Convert ToString with Caution

Ben Griswold — Fri, 04 Aug 2006 19:48:00 +0000

Assume we have a datarow field, name, which evaluates to null. What is the result of the following two cases?

CASE A
string name = Convert.ToString(dr["name"]);

CASE B
string name = dr["name"].ToString();

In the first case, Convert.ToString() will evaluate to null. In the second case, however, .ToString() will throw an exception. And it makes sense, doesn’t it? After all, “nothing” doesn’t have a ToString() function to execute!

So, do yourself a favor and use object.ToString() sparingly. Use is only when using non-null values. In cases where null is a possibility, use Convert.ToString().

Short-circuit Operators in C#

Ben Griswold — Wed, 02 Aug 2006 17:21:00 +0000

Do you know how to short-circuit operators? In C#, And (&) and Or (|) operators evaluate both boolean expressions in the statement. However, the && operator only evaluates the first Boolean if false and the || operator only evaluates the first Boolean if true. This technique prevents the execution of the second expression if unnecessary — therefore optimizing your logic.

//Avoid:
if (_username ==”" & _password == “”)
{
…
}

//Correct:
if (_username == “” && _password == “”)
{
…
}