Guard classes - use or not?

The other day I happened to make quite large changes in a single C # project - removing a third-party build. The most "wonderful" thing is that I spent the lion's share of time changing places where helperes from this assembly were used (as it were, a bonus to the main functionality).

Helper's of this type:

Guard.ArgumentNotNull(myobject, "myobject"); 

Such classes are very common, they can be formed into common libraries and migrate from project to project. But do they need them? The common opinion that such guard'y reduce the number of lines of code and increase clarity, but, as for me, this is a very subjective opinion. Here is an example:

 class Manager(IEventProvider eventProvider, IDataSource dataSource) { Guard.ArgumentNotNull(eventProvider, "eventProvider"); Guard.ArgumentNotNull(dataSource, "dataSource"); this.eventProvider = eventProvider; this.dataSource = dataSource; } 

 class Manager(IEventProvider eventProvider, IDataSource dataSource) { if (eventProvider == null) throw new ArgumentNullException("eventProvider"); if (dataSource == null) throw new ArgumentNullException("dataSource"); this.eventProvider = eventProvider; this.dataSource = dataSource; } 

Yes, there are more lines of code, but did the clarity hurt? Not.

Another opinion is that if necessary, perform checks for a large number of dependencies, the if (...) throw construct turns the code into a mess. I agree, but these are symptoms of design problems, not if (...) throw constructs.

An interesting argument on this topic is in the blog of Mark Siman .

What do you think?

PS There are more code contracts, which in the simplest form can be used for such checks.