The guard clause library that floats like a butterfly and stings like a butterfly
C# Ruby
Latest commit b7be4ed May 4, 2016 @adamralph adamralph Merge pull request #123 from liteguard/readme-footnote-italics-1
remove italics from footnotes
Failed to load latest commit information.
src increment to version 0.12.0 Sep 6, 2015
.editorconfig added .editorconfig and fixed whitespace Mar 17, 2015
.travis.yml fixed line endings - switched LF to CRLF Feb 9, 2013
Gemfile refactor: switch to bundler May 4, 2016
Gemfile.lock refactor: switch to bundler May 4, 2016 remove italics from footnotes May 4, 2016
license.txt added .editorconfig and fixed whitespace Mar 17, 2015
rakefile.rb refactor: re-use Guard.cs source files where possible Jun 28, 2015


*nix Build Status Windows Build Status

Why, it's lighter than air!

The guard clause library which stands out from the crowd like the faintest passing whisper.

You'll hardly know it's there!

Compatible with .NET 3.5, Mono 3.2.81, Windows Store 8, Windows Phone 8.1, Universal Apps 8.1, Xamarin.Android 1.0, Xamarin.iOS 1.0, Windows Phone Silverlight 8 and Silverlight 5 (and later versions of each).

Get it at NuGet.

1 LiteGuard is also compatible with most versions of Mono 2.x and earlier versions of Mono 3.x, but this is not proven by the CI build.

How do I use it?

public void Foo(Bar bar)
    Guard.AgainstNullArgument("bar", bar);
    Guard.AgainstNullArgumentProperty("bar", "Baz", bar.Baz);
    Guard.AgainstNullArgumentProperty("bar", "Baz.Bazza", bar.Baz.Bazza);

    // the rest of your method, nice and safe, wrapped in the protecting arms of LiteGuard

public void Foo<T>(T bar) where T : class
    Guard.AgainstNullArgument("bar", bar);

public void Foo<T>(T bar)
    Guard.AgainstNullArgumentIfNullable("bar", bar);

Why did we create it?

The aim of LiteGuard is to be the most simple, unambiguous and lightweight guard clause library available.

A very explicit DSL

The names of LiteGuard clauses are unambiguous to ensure correct usage. Misuse should be obvious.

public void Foo(Bar bar)
    var baz = GetBaz();
    Guard.AgainstNullArgument("baz", baz); // clearly incorrect - baz is not an argument

No fluent API

Some guard clause libraries provide a fluent API.

A fluent API requires the creation of objects which serve no purpose other than to provide an access point for the next method in the DSL. The creation of these objects decreases performance, increases memory usage and adds pressure to the garbage collector. It is our belief that a guard clause library has no business in doing this. It should use as few resources as possible and be eligible for use in as wide a set of applications as possible. We love a good fluent API but it has its places and a guard clause library is not one of them.

No business rule clauses

Many guard clause libraries provide a huge range of methods for determining whether arguments satisfy all manner of business rules.

In our opinion, it is not the job of a guard clause library to validate arguments against business rules. We believe the role of a guard clause library is to prevent method calls with null arguments or null argument values. Ideally, we'd like such things to be built into .NET languages. If that ever happens we will happily allow LiteGuard to retire gracefully to a small but comfortable home near the seaside with a carriage clock and a little Havanese.

Where do I get it?

Install it from Nuget. For update notifications, follow @adamralph.

To build manually, clone or fork this repository and see 'How to build'.

Can I help to improve it and/or fix bugs?

Absolutely! Please feel free to raise issues, fork the source code, send pull requests, etc.

No pull request is too small. Even whitespace fixes are appreciated. Before you contribute anything make sure you read

What do the version numbers mean?

LiteGuard uses Semantic Versioning. The current release is 0.x which means 'initial development'. Version 1.0 is imminent.


Our build server is kindly provided by CodeBetter and JetBrains.

YouTrack and TeamCity


LiteGuard logo designed by Vanja Pakaski.