Tom Goff's .Net Musings

Tidbits of information regarding .Net, C#, and SQL Server.

Double Initialization

leave a comment »

I was playing around with FXCop and ran into an interesting rule it was reporting on my code. The rule is called DoNotInitializeUnnecessarily, and reports a warning when you initialize a field member to it’s “default value”. The default value depends on the data type: zero (0) for integers, false for Booleans, null for reference types, etc. For example, the default value for the String field below is null, so there is no reason to explicitly set it to null:

    public class Class1 { 
        /// <summary> 
        /// Holds my string. 
        /// </summary> 
        private String myString = null; 

        /// <summary> 
        /// Gets my string. 
        /// </summary> 
        /// <value>My string.</value> 
        public String MyString { 
            get { 
                return this.myString; 
            } 
        } 
    }

Now, this isn’t much of a problem because this will get optimized out of release builds. Unfortunately, I almost always initialize Strings to String.Empty. So if I write:

    public class Class1 { 
        /// <summary> 
        /// Holds my string. 
        /// </summary> 
        private String myString = String.Empty; 

        /// <summary> 
        /// Gets my string. 
        /// </summary> 
        /// <value>My string.</value> 
        public String MyString { 
            get { 
                return this.myString; 
            } 
        } 
    }

Then the initialization will occur, regardless of whether it’s a release build. Obviously in this example, it’s not a problem because we want the string to be non-null. But, if we were to write:

    public class Class1 { 
        /// <summary> 
        /// Initializes a new instance of the <see cref="Class1"/> class. 
        /// </summary> 
        /// <param name="myString">My string.</param> 
        public Class1(String myString) { 
            this.myString = myString ?? String.Empty; 
        } 

        /// <summary> 
        /// Holds my string. 
        /// </summary> 
        private String myString = String.Empty; 

        /// <summary> 
        /// Gets my string. 
        /// </summary> 
        /// <value>My string.</value> 
        public String MyString { 
            get { 
                return this.myString; 
            } 
        } 
    }

Then the myString field will be initialized twice. First time, the field initializer sets it to String.Empty. Then in the constructor it’s initialized to the given parameter if it’s non-null, otherwise it’s set to String.Empty again.

To remove the double initialization, we need to remove the field initializer. I doubt that there are many cases were this would result in a noticeable speed improvement. Although, when things are running in long loops every little bit helps.

Things like this generally dictate how I will write code. I will probably avoid field initializers now, just so I don’t have to worry about double, or potentially triple, initialization. Field initializers were just a convenient way to set fields, but I didn’t realize there was a potential (albeit small) problem.

Advertisements

Written by Tom

May 11, 2007 at 12:54 pm

Posted in C#, Gotcha

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: