Quickduck

I really don’t like inefficiency in code. Some people would say I’m quite the coding nazi when it comes to stuff like this; I’m sorry, but I just don’t like having code that exists just because someone thinks “it makes it read more like english”. Sorry, but C# != English.

Don’t get me wrong; I’m all for writing clear, concise code. I strongly encourage using descriptive method names, and fully expressed variable names (e.g. “requestContext” instead of “rc”). But all I’m saying is, don’t over-do it! Here are three small tips you can use to work around small inefficiencies in your code.

Use System.Math
How many times have you come across a segment of code like this?

if (waitTimeMillis < MaxPingTime) {
    waitTimeMillis *= 2;
    if (waitTimeMillis > MaxPingTime) {
        waitTimeMillis = MaxPingTime;
    }
}

Sure, it looks pretty harmless, but we need to read three lines of code to work out that there is an upper limit on waitTime. We can better express that using the Math.Min function:

if (waitTimeMillis < MaxPingTime) {
    waitTimeMillis = Math.Min(waitTimeMillis * 2, MaxPingTime);
}

A boolean is a boolean
I remember one of our lecturers at uni first pointed this one out to me when we were learning java. Comparing a boolean expression to true or false is redundant - just evaluate the expression instead. So, don't do this - ever:

if (MyClass.IsInitialised == true) {
    RunPostInitialisation();
}

No folks, I don't want to see "== true" or "== false" in your code, ever. I guess it could be worse, you could have "!= true"... - either way, lets keep it simple:

if (MyClass.IsInitialised) {
    RunPostInitialisation();
}

Use ternary expressions instead of if/else
Do you really need that if/else clause?

if (house.NumberOfOccupants > 1) {
    house.MaximumNumberOfPets = 3;
} else {
    house.MaximumNumberOfPets = 2;
}

There are circumstances where an if/else clause may be justifiable; but in general, they aren't needed. A ternary expression is much more succinct:

house.MaximumNumberOfPets = house.NumberOfOccupants > 1 ? 3 : 2;

Where the values that you're using for the true/false evaluation of the expression are a bit more complex, you can separate this on to multiple lines to read a bit more clearly:

Type type = Instruments.ContainsKey(instrumentType)
    ? Instruments[instrumentType]
    : UnknownInstrumentType;

Code better!

I have to admit that I much prefer WPF over Windows Forms (but prefer ASP.Net to either). However, the programming model is still a bit immature (in my opinion), and sometimes things that you wish were simple just aren’t. Case and point: trying to programmatically select an item in a TreeView control; it just ain’t easy!

Anyway, after scrubbing the web and finding a few solutions that really didn’t appeal (e.g. using reflection; surely it’s not that hard!) I came up with this extension method which does the trick quite nicely.

/// <summary>
/// Walks the tree items to find the node corresponding with
/// the given item, then sets it to be selected.
/// </summary>
/// <param name="treeView">The tree view to set the selected
/// item on</param>
/// <param name="item">The item to be selected</param>
/// <returns><c>true</c> if the item was found and set to be
/// selected</returns>
static public bool SetSelectedItem(
    this TreeView treeView, object item) {

    return SetSelected(treeView, item);
}

static private bool SetSelected(ItemsControl parent,
    object child) {

    if (parent == null || child == null) {
        return false;
    }

    TreeViewItem childNode = parent.ItemContainerGenerator
        .ContainerFromItem(child) as TreeViewItem;

    if (childNode != null) {
        childNode.Focus();
        return childNode.IsSelected = true;
    }

    if (parent.Items.Count &gt; 0) {
        foreach (object childItem in parent.Items) {
            ItemsControl childControl = parent
                .ItemContainerGenerator
                .ContainerFromItem(childItem)
                as ItemsControl;

            if (SetSelected(childControl, child)) {
                return true;
            }
        }
    }

    return false;
}

(Forgive formatting; the code window is only so-wide.)

The trick, you see, is to use the ItemContainerGenerator on the ItemsControl – which TreeView and TreeViewNode both inherit from – to try to find the container for the item you are selecting. This will only work for the immediate children of the control that you’re calling it on – so asking your root node for the container for an item which is three nodes deep is fruitless; hence, you have to walk down the tree asking each branch node if it contains the item.

It’s possibly not the fastest executing code in the world – walking a tree rarely is – but you could speed things up if you knew where the parent node was; then you could just call the recursive method directly.

Enjoy!

Ever come across some code that just wreaks?

I’m talking the kind of smells like 500 line method implementations or methods that are located in the wrong class.

It’s amusing to see how developers go out of their way to hide their problems rather than fix them.

There are two code-smell hiding techniques I often see utilized in the C# Visual Studio space.

1. Wrap the offending code in a #region (and hope that others don’t have region expansion on by default)
2. Move the distracting/inappropriately placed members into a partial class

Most often though I find that developers seem proud of the smells as they don’t even bother to hide the fact that they’ve just left a big stinky guff for the next person to walk right into.

What code-smell hiding techniques have you been witness to? Or more importantly how do you hide your own smells?

I’ve often seen code that tries to get a numeric bit (1, 0) value for a boolean.

I know of three ways you can do it:

1. Manual condition checking
2. Use the GetHashCode() method
3. Use the built in .Net Convert class

All three approaches do the job however I find that using the Convert.ToByte(boolValue) makes the most sense from a readability stance.

The following examples mix it up a bit and accommodate a Nullable<bool>.

Let’s start with the scenario where true is 1 and false and null are 0.

   bool? tVal = true;
    bool? fVal = false;
    bool? nVal = null;

    // true = 1, false = 0, null = 0

    Assert.AreEqual(1, tVal.HasValue && tVal.Value ? 1 : 0);
    Assert.AreEqual(0, fVal.HasValue && fVal.Value ? 1 : 0);
    Assert.AreEqual(0, nVal.HasValue && nVal.Value ? 1 : 0);

    Assert.AreEqual(1, tVal.GetHashCode());
    Assert.AreEqual(0, fVal.GetHashCode());
    Assert.AreEqual(0, nVal.GetHashCode());

    Assert.AreEqual(1, Convert.ToByte(tVal));
    Assert.AreEqual(0, Convert.ToByte(fVal));
    Assert.AreEqual(0, Convert.ToByte(nVal));

Now let’s mix it up a bit and say that a null value should represent a TRUE or 1 value by default.
i.e. true = 1, null = 1, false = 0,

    bool? tVal = true;
    bool? fVal = false;
    bool? nVal = null;

    Assert.AreEqual(1, !tVal.HasValue || tVal.Value ? 1 : 0);
    Assert.AreEqual(0, !fVal.HasValue || fVal.Value ? 1 : 0);
    Assert.AreEqual(1, !nVal.HasValue || nVal.Value ? 1 : 0);

    Assert.AreEqual(1, (tVal ?? true).GetHashCode());
    Assert.AreEqual(0, (fVal ?? true).GetHashCode());
    Assert.AreEqual(1, (nVal ?? true).GetHashCode());

    Assert.AreEqual(1, Convert.ToByte(tVal ?? true));
    Assert.AreEqual(0, Convert.ToByte(fVal ?? true));
    Assert.AreEqual(1, Convert.ToByte(nVal ?? true));

Is there an easier, better or another alternate way to do this?

I’d love to hear your thoughts?

This article collates some good answers to resistive arguments for using Object Relational Mappers.

This article demonstrates 21 techniques you can employ to write usable CSS.

One of the things that pops up over and over in project development is the issue of when to create Custom Exceptions.

To come to any form of conclusion it’s necessary to understand the reason why you might create your own Exception class.

1. To allow typesafe error detection and act appropriately.
2. To add context specific data.
3. There’s no existing framework exception that signifies the error.

1. To allow typesafe error detection.

Creating a customized exception allows the receiver to act upon a specific error. Using this approach the receiver is forced to detect that specific error to perform any useful action.
Examples where creating a custom exception for this scenario to make sense include;

- situations where you may need to prompt a user to correct a problem (e.g. disk full exception)
or
- where you need to log specific exceptions.

2. To add context specific data.

By adding more context to an exception, the receiver of the exception can use this information to help track down and recover from the error.

An example; say the validation rules for an object instance fail, by attaching the validation rules to the exception the receiver may use them to display appropriate error messages on screen to help recover from the error.

E.g.

public class ValidationException : Exception {

  public ValidationException(ValidationResults results) : base(results.ToString())
  {
Results = results;
  }

  public ValidationResults Results {get;set;}
} 

public class ValidationResults : IEnumerable<KeyValuePair<string,string>> {

  public IEnumerator<KeyValuePair<string, string>> GetEnumerator() {
    ...
  }

  IEnumerator IEnumerable.GetEnumerator() {
    return GetEnumerator();
  }
}

Usage:

try {
  ...
  ...
} catch (ValidationException ve) {
  foreach (var result in ve.Results) {
    Console.WriteLine("Error:" + result.Key + " : " + result.Value);
  }
}

Alternately, the System.Exception class contains a Data Dictionary property that can be used to attach context without having to create your own customized exception class:
E.g.

var exception = new InvalidOperationException("ValidationException"); 

var validationResults = new Dictionary<string, string>();
validationResults["Name"] = "The Name value is too long.";
validationResults["Postcode"] = "The Postcode is invalid.";
exception.Data.Add("ValidationResults", validationResults);

throw exception;

The lack of type safety in the Data dictionary may be off-putting but using extension methods you can add some type safety.

public static IDictionary<string, string> GetValidationResults(this InvalidOperationException ioe)
{
  if (ioe.Data.Contains("ValidationResults"))
  {
    return ioe.Data["ValidationResults"] as Dictionary<string,string>;
  }
  return new Dictionary<string, string>();
}

public static string GetValidationMessage(this InvalidOperationException ioe, string key)
{
  if (ioe.Data.Contains("ValidationResults"))
  {
    return ((IDictionary<string, string>) ioe.Data["ValidationResults"])[key];
  }
  return null;
}

I find that using the Data dictionary approach may save you the benefit of creating a Custom Exception but at the expense of more verbose and un-intuitive code.
3.	There’s no existing framework exception that signifies the error.
The detail level to which you can specify an exception type is infinite. When it comes down to it there are few framework exception types that are valid for most scenarios:
Input value causes exception; throw one of 
System.ArgumentException

System.ArgumentNullException

   System.ArgumentOutOfRangeException
For all other errors a good default option is to use the System.InvalidOperationException.
Conclusion:
To sum up, think carefully about the specific scenario that is being addressed when writing exception logic, follow this checklist to help in your decision making.
Is there a need to act upon the specific exception and find a way to recover from it?
Yes -> Consider creating a generic custom exception.

For example create an exception named DuplicateEntityException rather than JobRateAlreadyExistsException.
No -> throw an existing exception type.
Do you need to log a specific error scenario?
Yes -> Consider creating a generic custom exception.

No -> throw an existing exception type.
Do you need extra information in the exception to respond effectively?
Yes -> Determine whether creating a custom exception with typesafe data members is more intuitive than using the Data dictionary on the System.Exception class.

No -> throw an existing exception type.
For all other scenarios default to throwing an existing exception type.
What are your thoughts and experiences on this issue?