Guard

Warning

This project is no longer actively maintained.

I apologise to everyone who depended on Guard for my three-year-long silence. Guard was my passion project for the longest time, helping me get better at C#, automated builds, Visual Studio extensibility, documentation, and how to be part of a community regardless of how small we've been. It also kickstarted my journey of creating terrible gifs.

But my life has changed - I moved to a different country, changed jobs, lost someone very dear to me, and started spending less and less time coding outside my work hours. I always believed I'd be back and release v2 with all my bright ideas, but I just didn't know when. I only noticed today that I've been avoiding my GitHub notifications out of guilt for over a year, and I figured it was time for closure.

Why I'm stopping this

I can no longer find the time to maintain an open-source project, as I want to spend most of my free time with my family and on other hobbies.
Guard has always been in an awkward position:

Library authors avoid adding unnecessary dependencies to their packages, and Guard didn't bring enough value to be worth being a runtime dependency. I wanted to experiment with IL weaving and source generators to make Guard a compile-time dependency that would replace call sites with simple if-then-throw statements, but I never got the chance.

App developers didn't need Guard as their validation scenarios doesn't involve throwing argument exceptions. For example, a web API would use something like DataAnnotation attributes or FluentValidation to validate its requests. So as a library that specifically targeted library authors, Guard has always been irrelevant to app developers.

What was I looking to do in v2:

New style with using static and [CallerArgumentExpression]:

// using static Dawn.Validation.Argument;

Require(firstName).NotNullOrWhiteSpace();

Lite validations with [CallerArgumentExpression]:

var ratio = 5.0;
Require(ratio).Range(ratio is >= 0.0 and <= 1.0);
// ArgumentOutOfRangeException
// * ParamName: "ratio"
// * ActualValue: 5
// * Message: "Failed precondition: 'ratio is >= 0.0 and <= 1.0'."

Hadn't yet decided whether the light validations would replace the custom ones or live in addition to them.

Type guards, e.g., Require<TImplementation>().NotAbstract();
Fixing nullable reference type issues
Changing the argument value to a ref field, which meant:
- We could even work on mutable structs without copying
- We could experiment with in-place normalisations
Dropping .NET Standard support

I hope this helps anyone who was waiting for the v2. Original intro below:

Guard is a fluent argument validation library that is intuitive, fast and extensible.

$ dotnet add package Dawn.Guard / PM> Install-Package Dawn.Guard

Introduction
What's Wrong with Vanilla?
Requirements
Standard Validations
Design Decisions
Extensibility
Code Snippets

Introduction

Here is a sample constructor that validates its arguments without Guard:

public Person(string name, int age)
{
    if (name == null)
        throw new ArgumentNullException(nameof(name), "Name cannot be null.");

    if (name.Length == 0)
        throw new ArgumentException("Name cannot be empty.", nameof(name));

    if (age < 0)
        throw new ArgumentOutOfRangeException(nameof(age), age, "Age cannot be negative.");

    Name = name;
    Age = age;
}

And this is how we write the same constructor with Guard:

using Dawn; // Bring Guard into scope.

public Person(string name, int age)
{
    Name = Guard.Argument(name, nameof(name)).NotNull().NotEmpty();
    Age = Guard.Argument(age, nameof(age)).NotNegative();
}

If this looks like too much allocations to you, fear not. The arguments are read-only structs that are passed by reference. See the design decisions for details and an introduction to Guard's more advanced features.

What's Wrong with Vanilla?

There is nothing wrong with writing your own checks but when you have lots of types you need to validate, the task gets very tedious, very quickly.

Let's analyze the string validation in the example without Guard:

We have an argument (name) that we need to be a non-null, non-empty string.
We check if it's null and throw an ArgumentNullException if it is.
We then check if it's empty and throw an ArgumentException if it is.
We specify the same parameter name for each validation.
We write an error message for each validation.
ArgumentNullException accepts the parameter name as its first argument and error message as its second while it's the other way around for the ArgumentException. An inconsistency that many of us sometimes find it hard to remember.

In reality, all we need to express should be the first bullet, that we want our argument non-null and non-empty.

With Guard, if you want to guard an argument against null, you just write NotNull and that's it. If the argument is passed null, you'll get an ArgumentNullException thrown with the correct parameter name and a clear error message out of the box. The standard validations have fully documented, meaningful defaults that get out of your way and let you focus on your project.

Requirements

C# 7.2 or later is required. Guard takes advantage of almost all the new features introduced in C# 7.2. So in order to use Guard, you need to make sure your Visual Studio is up to date and you have <LangVersion>7.2</LangVersion> or later added in your .csproj file.

.NET Standard 1.0 and above are supported. Microsoft Docs lists the following platform versions as .NET Standard 1.0 compliant but keep in mind that currently, the unit tests are only targeting .NET Core 3.0.

Platform	Version
.NET Core	`1.0`
.NET Framework	`4.5`
Mono	`4.6`
Xamarin.iOS	`10.0`
Xamarin.Mac	`3.0`
Xamarin.Android	`7.0`
Universal Windows Platform	`10.0`
Windows	`8.0`
Windows Phone	`8.1`
Windows Phone Silverlight	`8.0`
Unity	`2018.1`

The default branch (dev) is the development branch, so it may contain changes/features that are not published to NuGet yet. See the master branch for the latest published version.

Standard Validations

Click here for a list of the validations that are included in the library.

Design Decisions

Click here for the document that explains the motives behind the Guard's API design and more advanced features.

Extensibility

Click here to see how to add custom validations to Guard by writing simple extension methods.

Code Snippets

Code snippets can be found in the snippets folder. Currently, only the Visual Studio is supported.

crstnsz/guard