Before reading any further, please read the disclaimer in the C# Bloopers post.

When you declare a member variable, and then you try to read it from within the constructor without having first initialized it, you receive no warning about accessing an uninitialized member. This happens even if the member is declared as readonly.

namespace Test2  
{  
    public class Test 
    {  
        public readonly string m; 
        public string n; 
        protected readonly string o; 
        protected string p; 
        private readonly string q; 
        private string r; 

        Test() 
        {  
            m.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            n.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            o.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            p.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            q.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            r.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            q = "q"; //to prevent Warning CS0649: Field is never assigned to, and will always have its default value null 
            r = "r"; //to prevent Warning CS0649: Field is never assigned to, and will always have its default value null 
        }  
    } 
}  

Someone might argue that this is behavior is fine because the member in question is guaranteed to contain its default value. First of all, a readonly member containing its default value is completely useless. (See C# Blooper №1: No warnings about uninitialized readonly members) Secondly, if the compiler is to help the developer catch potential errors and write better code, this is not a valid excuse: a different strategy is necessary.

Please do not get me wrong; C# is awesome. It is the language of my choice, even though I am pretty well versed in C++ and Java. That having been said, it cannot be denied that C# has its share of flaws, too. In this series of posts I am documenting some of them, in no particular order.

Also please note that some of the issues described here are Visual Studio bloopers, or DotNet bloopers, and not C#-in-general bloopers.

Introduction

Hail Mary Initialization is the cargo cult programming practice of pre-initializing a local variable with some default value, "just in case", even though that value will subsequently be overwritten in all code paths before it will ever be read. It is commonly done under the impression that it reduces the chances of error, but in reality it achieves the exact opposite: it increases the chances of error.

(When the class is public and the member is public, protected or protected internal.)

Before reading any further, please read the disclaimer in the C# Bloopers post.

The C# compiler is kind enough to give you a "field is never assigned to" warning if you forget to initialize a readonly member which is private or internal, or if the class in which it is being declared is internal. But if the class is public, and the readonly member is public, protected or protected internal, then no warning for you! Why, oh why?

Note: This post has been superseded by a new post in 2022. See Intertwine.

This is a C# project that I did back in 2011. It consists of a (rather informal) white paper which describes the project, and a zip file containing the source code in the form of a Microsoft Visual Studio solution.

Here is the abstract:

A mechanism is proposed for converting (entwining) method call invocations of any interface to a general purpose single-method normal form, and converting back (untwining) from the normal form to interface invocations, so that operations can be performed on the normal form in a way agnostic to the interface being invoked. The normal form is a delegate in C# or a functional interface in Java, realized as object AnyCall( int selector, object[] parameters ). A DotNet implementation is provided in C#, though the discussion also applies to Java.

If you are a developer with any real-world experience to speak of, you have undoubtedly come across the following situation: you made a change which was not meant to be committed, (for instance, some debug statement or some mock-up of functionality meant to be filled-in later,) and then you forgot about it and went ahead and committed all of your code. This mishap can be a cause of severe frustration for your fellow co-workers, and the source for memorable "WTF moments" for the QA department.