If you are coming to this series of posts for the first time you might check out my introductory post for a little context.
VerifyArgs is another approach to a guard helper that takes an interesting approach.
Verify.NotNullOrEmpty(new { first, second });
Verify.Positive(new { secondCount });
Many of you might look at the above and think ?But what about performance?? If that?s you, I?d have to say go test it out for yourself. But for nearly all cases out there I don?t think this level of performance is anything to be concerned with. The project?s home site has a little blip that tries to address the performance concern.
This project is great because of the fluent nature of each Verify.***
All these fluent interface libraries seem overkill. Sure it looks fancy, but there is so much extra execution overhead, What ever happened to the good old Assert.IsNotNull, or, multiple assert calls. When you have code that has a high execution rate, these kinds of fluent designs are terrible.
I still fail to see what’s wrong with Assert.IsNotNull, it works, and everybody knows how it works.
Wow — I just recently posted my own code that does this *exact* thing:
http://www.daedtech.com/poor-mans-code-contracts
In my case, though, I use an instance method rather than a static one so that you can swap out validation behavior at runtime with wireup or an IoC container (e.g. throw exceptions during development, log problems in release). I also have a handy parameterized one on there so that you can validate multiple references in one call.
It’s interesting that there seem to be multiple, parallel efforts to have lightweight code contracts. I’m glad that I’m not the only one interested in eliminating boilerplate.