Monthly Archives: June 2010

Use Preprocessor Directives for better debugging

The most common use for Preprocessor Directives is to intelligently group your code using the #region … #endregion tag (sidenote: Ctrl + M, M is a great keyboard shortcut to expand and contract your regions).  Preprocessor Directives can also be used to tell the compiler which code should or should not be compiled based on the configuration environment.  Wrapping code in an #if DEBUG … #endif block will only execute if the environment is in debug mode.

This proved to be a handy way to debug a situation this morning in a multi-threaded scenario where breakpoints and Console.WriteLine were not giving me enough information.  I added a new tab with initial visibility as collapsed, set it to visible in an #if DEBUG … #endif block, and wrote events to it also in a debug block.

For situations where you want code to execute only in a production environment, use #if !DEBUG … #endif.

View MSDN’s page on Preprocessor Directives for more information.



Get to No as fast as possible

 

There is a sales technique where the strategy is to get the customer to say “No deal” as soon as possible.  The idea being that by establishing terms that your customer is not comfortable with with, the sooner you can figure out what they will be willing to agree to.  The same principal can be applied to code design.  Instead of nested if…then statements, a code block should quickly eliminate the cases it is not equipped to handle and just focus on what it is meant to handle.

This is code that will quickly become unmaintainable as requirements change:

private void SaveClient(Client c)

{

    if (c != null)

    {

        if (c.BirthDate != DateTime.MinValue)

        {

            foreach (Sale s in c.Sales)

            {

                if (s.IsProcessed)

                {

                    SaveSaleToDatabase(s);

                }

            }

            SaveClientToDatabase(c);

        }

    }

}

 

If an additional requirement comes along that requires the Client to have Manager approval or for a Sale to be under $20K, this code will get messy and unreadable.

A better way to meet the same requirements would be:

private void SaveClient(Client c)

{

    if (c == null)

    {

        return;

    }

    if (c.BirthDate == DateTime.MinValue)

    {

        return;

    }

 

    foreach (Sale s in c.Sales)

    {

        if (!s.IsProcessed)

        {

            continue;

        }

        SaveSaleToDatabase(s);

    }

    SaveClientToDatabase(c);

}

This technique moves on quickly when it finds something it doesn’t like.  This makes it much easier to add a Manager approval constraint.  We would just insert the new requirement before the action takes place.



Use Extension Methods to find first and last day of the month

A lot of reports work on data from last month.  It is a nice touch to have these dates pre-populated for your users.  Using extension methods, the code can look cleaner too.

Extension Methods:

public static class DateHelper

{

    public static DateTime FirstOfTheMonth(this DateTime dt)

    {

        return new DateTime(dt.Year, dt.Month, 1);

    }

 

    public static DateTime LastOfTheMonth(this DateTime dt)

    {

        return dt.FirstOfTheMonth().AddMonths(1).AddDays(-1);

    }

}

Consuming Code:

void Prepopulate()

{

    startDateBox.CurrentlySelectedDate = DateTime.Now.AddMonths(-1).FirstOfTheMonth();

    endDateBox.CurrentlySelectedDate = DateTime.Now.AddMonths(-1).LastOfTheMonth();

}



Declaring variables in SQL

I would like to blog more about the problems I encounter on a daily basis.  I find that taking 10 minutes or so to write a simple solution to my problems helps me retain that information.

I always forget the specific syntax to declaring variables in T-SQL. 

declare @startdate datetime;

declare @enddate datetime;

 

set @startdate = '04/01/2010';

set @enddate = '04/30/2010';

 

select count(id) from triphistory where tripdate between @startdate and @enddate