Software Engineering

Generic custom configuration elements collection based on ConfigurationElementCollection

Paul Petrov — Tue, 13 Nov 2007 19:32:37 GMT

Simple trick that saves me some time and coding when writing custom configuration objects is to define generic collection for them. Let's say I created several custom configuration elements derived from my CustomConfigElementBase which in turn inherits from System.Configuration.ConfigurationElement. Instead of defining strongly typed collections for each type I can simply define class:

public class GenericConfigElementCollection<T> : ConfigurationElementCollection

where T : CustomConfigElementBase, new()

{

public T this[int index]

{

get

{

return base.BaseGet(index) as T;

}

set

{

if (base.BaseGet(index) != null)

base.BaseRemoveAt(index);

base.BaseAdd(index, value);

}

protected override ConfigurationElement CreateNewElement()

{

return new T();

}

protected override object GetElementKey(ConfigurationElement element)

{

return ((T)element).ElementKey;

}

Note, that base custom configuration element has property ElementKey to satisfy GetElementKey method implementation. If your custom elements have different keys, you can override this property. It's possible to skip CustomConfigElementBase and define generic collection with ConfigurationElement type restriction. GetElementKey implementation would use reflection to retreive key property:

public class GenericConfigElementCollection<T> : ConfigurationElementCollection

where T : ConfigurationElement, new()

{

protected override object GetElementKey(ConfigurationElement element)

{

//- find and return property which is a key for a given type T using reflection

...

}

Now, when we define configuration section we just return generic collection of appropriate type:

public class MyCustomConfigSection : ConfigurationSection

{

[ConfigurationProperty("myCustomSettings", IsRequired = true)]

public GenericConfigElementCollection<MyCustomConfigElement> MyCustomSettings

{

get

{

return this["myCustomSettings"]

as GenericConfigElementCollection<MyCustomConfigElement>;

}

And then just use it in an application code:

GenericConfigElementCollection<MyCustomConfigElement> configCollection = configSection.MyCustomSettings;

MyCustomConfigSection configSection = (MyCustomConfigSection)ConfigurationManager.GetSection("mySection");

The Daily WTF for Dummies

Paul Petrov — Tue, 29 May 2007 22:51:22 GMT

I don't know why this site changed it's good ol' name from The Daily WTF to "politically correct" WorseThanFailure but I wouldn't do it in my case. I happen to perform code reviews on Java to .Net migration recently and in both I find enough "programming pearls" to keep me saying WTF every day for weeks. I thought about posting some of them and sharing the link with creators of such masterpieces as I may guess who's behind. They might get angry at me but it's for good to let them learn from their mistakes (if capable).

There's a Russian book for children by Gregory Oster. The title translates like Harmful Advice for Naughty Children and Their Parents. Unfortunately, it's not been translated in English yet. It's filled with sarcastic rhymes and stories that will make your abs sore of laughing. The only English reference to this book I found is here. The book "teaches" kids to do bad things in quite humorous fashion.

I compiled some "tips" from code reviews in the manner of "The Harmful Advice: For Lamer Programmers and Wannabies". Code is stripped and de-personated so no harm to business only to developer's ego perhaps:

1. Whenever you use ADO.NET open as many DataReaders as possible and do not close them when done. Better yet, open several of them in nested loops. It's OK to keep connections open, that's what connection pools for, right?

2. When you get the data back in the DataReader, religiously check the data field for null:

    if(dataReader[0] != null)
    { myVal = dataReader[0];
    }

Sometimes, it's good to double check later down the road:

    if(myVal != null){}

It's all about defensive programming. And never trust DbNull and IsDbNull method of the DataReader.

3. Don't rely on reference types (.NET), they are evil. In most important cases pass them using ref keyword:

    SomeMethod(int param1, string param2, ref SomeClass imfeelingspecial);

4. Value types in .Net are more useful than you'd think. On a good day they can pass your data in and out just as easy as reference types:

SomeStruct commonInfo = new SomeStruct();

commonInfo.Field = “Let's see.”;

...

FoodProcessor proc = new FoodProcessor(commonInfo);

proc.MunchData(); //- munches data and re-assigns commonInfo fields

...

if(commonInfo.Field == "Expected Value From FoodProcessor")

{// <- lots of prayers needed to make it here!

else

{//- Doh! It always comes here anyways...

5. Do not trust SQL select results, it's not always obvious how many columns it returns. Make a habilt of checking the columns count in the resordset:

string sqlQuery = "SELECT column1, column2, column3 from SomeTable WHERE column4 = " + someVal;

...

 if (reader.Read())

     int fcnt = reader.FieldCount;

     if (fcnt >= 1)

         var1 = reader.GetString(0);

     if (fcnt >= 2)

         var2 = reader.GetString(1);

6. For money calculation always use low precision floating data types:

Float itmPrice = new Float(getIn().getRecords(count).getItemPrice());

Float itmQty = new Float(getIn().getRecords(count).getItemQuantity());

float exPrice = itmPrice.floatValue() * itmQty.floatValue();

extendPrice = extendPrice.valueOf(exPrice);

So, in this Java example, for itmPrice = 2.66 and itmQty=995 you will get a nice special price of 2646.7002. Decimal arithmetic is for pedants.

7. Always warm up the CPU before performing date calculations. This can be achieved by using many variables of different types and converting them back in forth to each other:

      Calendar myCal = Calendar.getInstance();

      myCal.setTime(myDate);

      Float fltTermNbr = new Float(newSrvcTerm);

      Float sevenDays = new Float("7");

      float fltTermNbrInDays = fltTermNbr.floatValue() * sevenDays.floatValue();

      String strTermNbrInDays = "";

      strTermNbrInDays = strTermNbrInDays.valueOf(fltTermNbrInDays);

      strTermNbrInDays = strTermNbrInDays.substring(0, strTermNbrInDays.indexOf("."));

      Integer IntegerTermNbrInDays = new Integer(strTermNbrInDays);

      int intTermNbrInDays = IntegerTermNbrInDays.intValue();

      myCal.add(myCal.DAY_OF_YEAR, intTermNbrInDays);

Just for us, lazy ones, all the Java code above is trying to do is:

int termNbrInDays = Convert.ToInt32(newSrvcTerm) * 7;
myDate = myCal.AddDays(myDate, termNbrInDays);

Still suck at writing bad code? Consider a mentor. Hire a developer with the thickest resume and largest amount keywords in it. At the end, one must be really hardworking to create one. Give him a title he wants: usually Lead Architect or something like this. Let him write the code and teach others. Well, I have to go back and dig up some more jewels...

Re. MSF 4.0 and Microsoft Team Services

Paul Petrov — Wed, 21 Dec 2005 19:47:00 GMT

Good post about MSF 4.0 by Charles Young.