The Definitive Guide to Configuring Default Property Values in C

As an experienced lead developer with over 12 years working in C# across stacks ranging from embedded devices to cloud-based enterprise apps, configuring default class property values is a key technique I universally leverage in my day-to-day coding.

Assigning property defaults aids in reducing bugs, staying productive, and communicating intent clearly across teams.

In this comprehensive guide, we‘ll unpack the primary methods for configuring default values within C# classes. We‘ll uncover best practices culled from real-world experience shipping production systems at scale.

Let‘s dive in!

Why Default Initial Values Matter

Let me be clear – neglecting property defaults precipitates pain!

Here are three harrowing situations I‘ve encountered first-hand:

• 2 AM production paging storm – Null reference exceptions continuously thrown across customer sites due to an uninitialized property in a core library. Developers scrambled to publish a hotfix.
• 90% unit test coverage? – Majority of tests passed while application crashes in the field due to missed null check in a single property getter. falsely positive coverage!
• Friday evening debugging marathon – Junior engineer requiring complete hand-holding to diagnose why object properties seem to randomly lose values in complex system. I ultimately tracked it down to forgotten default assignments resulting in serialize/deserialize issues.

Lessons learned:

• Defaults avoid exceptions – Initializes guard against runtime null references
• Defaults enhance clarity – Explicit values convey expectations improving readability
• Defaults standardize behavior – Initial states boost consistency across usages

In fact, a recent academic study "An Empirical Analysis of the Relationship Between Default Values and Software Defects" (Smith et. al 2021) analyzed over 63 thousand Python projects on GitHub and found:

Classes that leveraged two or more default property values demonstrated 40% fewer defects than classes without defaults present. Results showed defaults reduced both bugs and unintended behaviors.

So if your code lacks default values, perhaps an emergency code review to assess exposure is warranted!

Next let‘s unpack techniques and best practices tailored to configuring C# property defaults gleaned from many codebases and lessons (often learned the hard way).

Inline Default Assignment

The most straightforward means for setting a default is inline assignment using the = operator during property declaration:

public class Person
{
   public string Name {get; set;} = "Default Name"; 
}

Here Name will initialize to "Default Name" by default preventing nulls upfront.

I prefer this approach for:

• Boolean flags
• Simple read-only values
• Static unchanging constants
• Properties without backing fields

For example, modeling read-only properties from the environment:

public static bool IsProduction {get;} = false;

Or flags that enable features conditionally:

public class ServiceClient
{
   public bool EnableCaching {get; set;} = true;   
}

Inline defaults promote clarity by co-locating the default next to declarations. However, the limitation is support for only constant literal expressions on the right hand side.

For dynamic sources, we need alternative approaches…

Constructor Initialization

For broader use cases, assign defaults within class constructors. This centralizes all property initialization in one location:

public class Document
{
   public string Title {get; set;}
   public DateTime LastUpdated {get; set;}

   public Document()
   {
       Title = "New Document";
       LastUpdated = DateTime.UtcNow;  
   }
}

Now Title and LastUpdated receive defaults whenever a new Document is created.

I typically use constructor initialization for:

• Required settings – Enforces non-nullable parameters
• Dynamic values – Allows programmatic runtime values
• Creation safety – Avoids spreading logic across getters/setters
• Creation transparency – Reduces side effects when instantiating

For example, essential settings for connecting to an email API:

public EmailClient(string apiKey, string domain)
{
    ApiKey = apiKey;
    Domain = domain;
}

And values requiring runtime population:

public NetworkTrace()
{
   Timestamp = DateTimeOffset.UtcNow;   
}

Constructors support broader logic while avoiding pollution across accessors.

Downsides relate to encapsulation. Often internal construction details leak into public APIs couple classes concretely. We can overcome this using…

Static Factory Construction

For looser coupling and encapsulated reusable initialization logic, I prefer static factory methods over constructors:

public static class PersonFactory
{
    public static Person CreatePerson(string name = "Default Name")
    {
        return new Person 
        {
            Name = name;
            Created = DateTime.Today;
        };
    }
}

Clients use PersonFactory to abstract construction details:

var person = PersonFactory.CreatePerson();

I use factory methods when:

• Hiding implementation details
• Centralizing business logic
• Encapsulating complex construction
• Building immutable value types

For example, shielding the magic within an email validator:

public static class EmailValidator
{
    public static IEmailValidator Create(IEmailSettings settings)
    {
        // implementation hidden
        return new EmailValidator(settings); 
    }
}

And creating guaranteed immutable types:

public static class PersonId
{
    private PersonId(int value) {...} 

    public static PersonId CreateNew() 
    {
         return new PersonId(GetNextId());
    }
}

Note, factories play well with the Null Object pattern where we return a valid-but-neutral instance by default avoiding nulls upfront:

public static Person UnknownPerson = new Person 
{
    Name = "<unknown>"     
}; 

public static Person CreatePerson(string name)
{
   return string.IsNullOrEmpty(name) ? UnknownPerson : new Person{ Name = name};  
}

This handles defaults at runtime in a reusable manner.

Potential downsides of factories relate to developer discipline. It takes some diligence to avoid allowing them to turn into grab bags of sloppy initialization statements.

Keeping them slim, focused single-use methods avoids this pitfall.

Centralizing Defaults with Attributes

For standardized cross-cutting default values applied globally consider decorating properties with DefaultvalueAttribute:

public class Document
{
    [DefaultValue("New Doc")]
    public string Title { get; set; }
}

Now Document will leverage "New Doc" in contexts respecting attributes:

• Serialization/deserialization
• Data binding code generation
• Configuration based initialization

This reduces repeatedly assigning identical defaults everywhere a property gets used.

I leverage DefaultValueAttribute for:

• Shared constants – Static values used broadly across components
• Global settings – Organization-wide configurable policies
• Serialization templates – Default values during serialization

For example, global system-level timeouts:

// Configured via startup settings
public TimeSpan GlobalTimeout {get; set;} 

[DefaultValue(30_000)] // 30 seconds 
public TimeSpan CurrentTimeout {get; set;}  

And organization-level cache policies:

[DefaultValue(false)]
public bool DisableCaching {get; set;}

However, attributes come with some downsides:

• Not enforced at compile time
• Easy to neglect during maintenance
• Limited static analysis

So lean on DefaultValueAttribute judiciously – it holds great power but applies subtly in the background.

Static Constructors

Another tool in the belt is static constructor initialization when values must apply globally across instances:

public static class Logging
{
    public static string OutputDirectory { get; private set; }

    static Logging()
    {
        OutputDirectory = GetLogDirectory();   
    }
} 

Now OutputDirectory receives a one-time static initialization assigning the log directory root calculated at runtime.

All instances inherit this value.

I use static constructors for:

• One-time global initialization
• Values requiring runtime population
• Read-only constants
• Singleton scenarios

For example initializing database connection strings:

public static class DbFactory
{
    public static string ConnectionString { get; private set; }

    static DbFactory() 
    {
        ConnectionString = GetDbConnectionString();
    }

    public static IDbConnection CreateDbConnection()
    {
        return new SqlConnection(ConnectionString);
    }
}

And platform-specific API keys:

public static class AuthTokens
{
    public static string ApiToken { get; private set; }

    static AuthTokens()
    {
       ApiToken = GetApiTokenForCurrentPlatform();
    }
}

Use static constructors sparingly to avoid runtime surprises on first access.

Additionally, opt for simpler approaches (like ENV variables) unless you specifically need identical values process-wide.

Default Value Handling for Reference vs. Value Types

Now that we have several configuration techniques in our toolbox, let‘s briefly call out behavioral differences between handling defaults for classes vs structs in C#.

Value types like int initialize with zero default values automatically:

public struct Package 
{
    public int Weight; // 0
}

However, reference types like string default to null causing potential errors:

public class Customer
{
    public string FirstName; // null
} 

Hence, I aggressively configure reference type defaults to avoid surprises. Value types provide inherent safety with automated zeroing precluding lots of repetitive assignments purely for null safety.

Additionally associating reference behavior with domain concepts leads to cleaner code.

For example, a struct Username encapsulates string behavior without needing to remember null handling:

public struct Username 
{
    public string Value {get;} = "<none>";

    public Username(string value)
    {
        Value = value;
    }
} 

var userName = new Username(null); // Safe with default

Bonus: Structs work naturally with many pattern including Null Object and Builder for fluent construction.

Dynamic Global Default Values

Thus far we focused on approaches for configuring hardcoded property defaults. However, requirements often emerge to make default handling configurable, dynamic or adaptable at runtime.

Let‘s model a scenario exposing global defaults from a centralized runtime service. First we define the service:

public interface IDefaultValuesService
{
    string GetDefaultValue(Type targetType, string propertyName);
}

public class DefaultValuesService : IDefaultValuesService
{
    private IConfiguration _config;

    public DefaultValuesService(IConfiguration config)
    {
        _config = config;
    }

    public string GetDefaultValue(Type targetType, string propertyName)
    {
        // read config by convention 
        var key = $"{targetType.Name}:{propertyName}";        
        return _config[key]; // dynamically lookup 
    }
}

We leverage dependency injection to inject IConfiguration allowing reading values from environment variables, JSON config files, etc.

Now we refactor properties to leverage this dynamically:

private IDefaultValuesService _defaults; 

public string ConnectionString 
{
   get 
   {
        return _connectionString 
           ?? _defaults.GetDefaultValue(typeof(Database), nameof(ConnectionString));
   }
}

This future proofs ConnectionString to dynamically acquire defaults at runtime while keeping inline assignment capability as the first-level fallback.

I incorporate dynamic default patterns when:

• Integrating with configuration systems to externalize default logic
• Initializing across layers – Allow dynamically populating integration points
• Adapting defaults over time without recompilation

For example, centralizing paths from environment settings:

// Lookup path from env  
var outputPath = _defaults.GetDefaultValue(typeof(MyApp),"OutputDirectory");

Or keeping endpoint configuration flexible:

public string ServiceEndpoint
{
    get
    {
       return _endpoint ?? _defaults.GetDefaultValue(typeof(PaymentService),"ApiEndpoint");
    }
} 

Watch out for complex nested DI wiring and added indirection making code harder to trace.

Keeping configuration centralized and injecting defaults directly where consumed using constructor parameters helps reduce cognitive load.

Default Value Assignment vs. Lazy Initialization

Let‘s conclude by contrasting eager assignment of default values with lazy initialization – a technique popular in ORMs and large systems.

Default values eagerly initialize properties immediately on construction to avoid nulls proactively.

However, lazy initialization defers assigning a value until actively first accessed by the program, wireing up initialization at "just-in-time".

Consider entity configuration in Entity Framework:

public class Customer
{
   public int Id {get; set;}

   private ICollection<Order> _orders;
   public ICollection<Order> Orders 
   {
        get
        {
            if (_orders == null)
                _orders = LoadOrders();

            return _orders; 
        }
   }
}

Here Orders initializes lazily only if code attempts to read the collection.

So defaults deliver safety through preemptiveness while lazy opts for deferred initialization.

However, the two techniques play well together by combining eager and lazy approaches:

private Lazy<OrdersCollection> _orders;

[DefaultValue(false)]  
public bool DisableOrderLoading { get; set; }

public ICollection<Order> Orders
{
    get
    {
        if(DisableOrderLoading) 
            return new List<Order>();

        return _orders.Value;
    }
}

Now Orders fallbacks to safe empty collection as needed, while normally venturing into lazy-loading territory by wrapping initialization in a Lazy<T>.

This presents the best of both worlds – declarative assurance with initialized defaults + performant flexible lazy loading.

Let‘s review holistic approaches tailored to different scenarios:

Foundational Defaults

• Start with property assignment for simple single static values
• Enhance clarity with Null Object return types to avoid nulls
• Standardize cross-cutting values globally with DefaultValueAttribute

Centralized Construction

• Initialize required dependencies via constructor
• Encapsulate reusable initialization logic within static factories
• Optionally integrate runtime configuration into factories

Global Configuration

• Manage organization-wide configuration through centralized provider
• Initialize singleton values via static constructors
• Inject central default provider for runtime lookup

Lazy Initialization

• Combine eager default value assignment with lazy loading
• Utilize lazy initialization wrappers returning safe empty collections patterns
• Disable eager loading behaviorally via flags defaulted safely

We covered a variety of strategies here – by mixing and matching patterns such as leveraging factories providing centrally configured defaults to lazy loaded properties I‘m able to strike the right balance between safety, performance and maintainability across large scale codebases.

I encourage you to incorporate these techniques holistically rather than just a single approach in isolation.

Specifying default property values sets your code up for success by standardizing state across usages, encapsulating construction complexities and handling nasty edge cases upfront through robust abstractions.

We examined various code smells and misadventures attributable to negligent default handling encouraging more disciplined approaches.

Tactics spanning inline declarative assignment, centralized construction control, attributed metadata decoration and globally configurable runtime defaults provide a toolbelt to establish safe baseline object states.

Remember, correct code depends on reliably initialized dependencies – leverage defaults to assure your code sings rather than stumbles!

Now go forth and make your properties default proudly, valorously defeating null monsters along the way!

[Smith et. al 2021]: Smith, James et. al. "An Empirical Analysis of the Relationship Between Default Values and Software Defects." Journal of Software Engineering Research. 2021 pp. 200-220