Method Name Suggestion: Validate a Poor Choice? - CSharp

Call it nValidate

"Mike Hofer" <kchighland@gmail.com> wrote in message
news:1192125581.751465.250520@v3g2000hsg.googlegroups.com...
> Please forgive the cross-post to multiple forums. I did it
> intentionally, but I *think* it was appropriate given the nature of my
> question.
>
> I'm working on an open source code library to help automate and clean
> up parameter validation code. It's almost ready to go into open beta.
> But one last little glitch is holding me up, and that would be the
> name of the factory class that serves as the entry point into the
> library: Validate.
>
> Essentially, when you invoke the methods in this thing, your code
> looks like this:
>
> Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz")
>
> This works beautifully so far, but it becomes problematic when you use
> it from ASP.NET pages, where a Validate method is already defined. As
> you can imagine, the compiler thinks you're trying to invoke the
> Validate method on the page; so invoking one of the That methods on
> the Validate class (a factory) makes no sense.
>
> You can get around it by using an alias with the namespace and change
> to Verify or something:
>
> using NValidate.Framework.Validate = Verify;
>
> However, this creates a lot of manual work for the developer. It would
> seem that the onus is on *me* as the publisher of the library to come
> up with a solution. I mean, the whole POINT of this thing is to make
> our lives easier.
>
> So here's what I'm thinking: I could change the name of the Validate
> class to Verify. That gets around the whole problem with ASP.NET
> pages. That leaves only the following real concerns:
>
> 1.) Verify, like Validate before it, is a *very* common word. It's
> likely that it will conflict with existing method names.
>
> 2.) The product name is NValidate. (Yep, just like NUnit, NCover,
> NAnt, etc.) There might be a perceived disconnect between the product
> name and the primary entry point into the library itself. (Validate
> vs. Verify.)
>
> 3.) The classes that validate parameters are called validators. Again,
> it's the same disconnect.
>
> My questions for you folks with far greater experience than myself
> are:
>
> 1.) Is the difference between the product name and the method name
> that critical?
>
> 2.) Is there a better way to name the factory class?
>
> I'm pretty desperate for input here as this is a one-man project so
> far. Any help you big brained-folks can provide will be greatly
> appreciated. For those who are interested, I can provide links to the
> materials and the source code under development. (I won't spam the
> boards--I'm not marketing something here. I'm trying to solve a
> problem, and I don't know the best way to do it.)
>
> Again, thanks for your help.
>

Be more explicit with your naming, FactoryClassValidation,
CleanMyRoomValidation etc... its a judgment call to avoid becoming verbose
but the other extreme is terse naming which does not communicate or implies
unintended meanings.

Explicit Naming = Elegant Code

-
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/




"Mike Hofer" <kchighland@gmail.com> wrote in message
news:1192125581.751465.250520@v3g2000hsg.googlegroups.com...
> Please forgive the cross-post to multiple forums. I did it
> intentionally, but I *think* it was appropriate given the nature of my
> question.
>
> I'm working on an open source code library to help automate and clean
> up parameter validation code. It's almost ready to go into open beta.
> But one last little glitch is holding me up, and that would be the
> name of the factory class that serves as the entry point into the
> library: Validate.
>
> Essentially, when you invoke the methods in this thing, your code
> looks like this:
>
> Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz")
>
> This works beautifully so far, but it becomes problematic when you use
> it from ASP.NET pages, where a Validate method is already defined. As
> you can imagine, the compiler thinks you're trying to invoke the
> Validate method on the page; so invoking one of the That methods on
> the Validate class (a factory) makes no sense.
>
> You can get around it by using an alias with the namespace and change
> to Verify or something:
>
> using NValidate.Framework.Validate = Verify;
>
> However, this creates a lot of manual work for the developer. It would
> seem that the onus is on *me* as the publisher of the library to come
> up with a solution. I mean, the whole POINT of this thing is to make
> our lives easier.
>
> So here's what I'm thinking: I could change the name of the Validate
> class to Verify. That gets around the whole problem with ASP.NET
> pages. That leaves only the following real concerns:
>
> 1.) Verify, like Validate before it, is a *very* common word. It's
> likely that it will conflict with existing method names.
>
> 2.) The product name is NValidate. (Yep, just like NUnit, NCover,
> NAnt, etc.) There might be a perceived disconnect between the product
> name and the primary entry point into the library itself. (Validate
> vs. Verify.)
>
> 3.) The classes that validate parameters are called validators. Again,
> it's the same disconnect.
>
> My questions for you folks with far greater experience than myself
> are:
>
> 1.) Is the difference between the product name and the method name
> that critical?
>
> 2.) Is there a better way to name the factory class?
>
> I'm pretty desperate for input here as this is a one-man project so
> far. Any help you big brained-folks can provide will be greatly
> appreciated. For those who are interested, I can provide links to the
> materials and the source code under development. (I won't spam the
> boards--I'm not marketing something here. I'm trying to solve a
> problem, and I don't know the best way to do it.)
>
> Again, thanks for your help.
>

Mike,

Personally, I think that you should name Validate Validator. Generally,
for my objects, I like the type names to be nouns (not verbs) and the
methods to be verbs.

I know it kind of breaks the flow you are trying to achieve, but it
would work.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"Mike Hofer" <kchighland@gmail.com> wrote in message
news:1192125581.751465.250520@v3g2000hsg.googlegroups.com...
> Please forgive the cross-post to multiple forums. I did it
> intentionally, but I *think* it was appropriate given the nature of my
> question.
>
> I'm working on an open source code library to help automate and clean
> up parameter validation code. It's almost ready to go into open beta.
> But one last little glitch is holding me up, and that would be the
> name of the factory class that serves as the entry point into the
> library: Validate.
>
> Essentially, when you invoke the methods in this thing, your code
> looks like this:
>
> Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz")
>
> This works beautifully so far, but it becomes problematic when you use
> it from ASP.NET pages, where a Validate method is already defined. As
> you can imagine, the compiler thinks you're trying to invoke the
> Validate method on the page; so invoking one of the That methods on
> the Validate class (a factory) makes no sense.
>
> You can get around it by using an alias with the namespace and change
> to Verify or something:
>
> using NValidate.Framework.Validate = Verify;
>
> However, this creates a lot of manual work for the developer. It would
> seem that the onus is on *me* as the publisher of the library to come
> up with a solution. I mean, the whole POINT of this thing is to make
> our lives easier.
>
> So here's what I'm thinking: I could change the name of the Validate
> class to Verify. That gets around the whole problem with ASP.NET
> pages. That leaves only the following real concerns:
>
> 1.) Verify, like Validate before it, is a *very* common word. It's
> likely that it will conflict with existing method names.
>
> 2.) The product name is NValidate. (Yep, just like NUnit, NCover,
> NAnt, etc.) There might be a perceived disconnect between the product
> name and the primary entry point into the library itself. (Validate
> vs. Verify.)
>
> 3.) The classes that validate parameters are called validators. Again,
> it's the same disconnect.
>
> My questions for you folks with far greater experience than myself
> are:
>
> 1.) Is the difference between the product name and the method name
> that critical?
>
> 2.) Is there a better way to name the factory class?
>
> I'm pretty desperate for input here as this is a one-man project so
> far. Any help you big brained-folks can provide will be greatly
> appreciated. For those who are interested, I can provide links to the
> materials and the source code under development. (I won't spam the
> boards--I'm not marketing something here. I'm trying to solve a
> problem, and I don't know the best way to do it.)
>
> Again, thanks for your help.
>

On Oct 11, 2:27 pm, "clintonG" <nob...@nowhere.com> wrote:
> Be more explicit with your naming, FactoryClassValidation,
> CleanMyRoomValidation etc... its a judgment call to avoid becoming verbose
> but the other extreme is terse naming which does not communicate or implies
> unintended meanings.
>
> Explicit Naming = Elegant Code
>
> -
> <%= Clinton Gallagher
> NET csgallagher AT metromilwaukee.com
> URLhttp://clintongallagher.metromilwaukee.com/
>
> "Mike Hofer" <kchighl...@gmail.com> wrote in message
>
> news:1192125581.751465.250520@v3g2000hsg.googlegroups.com...
>
>
>
> > Please forgive the cross-post to multiple forums. I did it
> > intentionally, but I *think* it was appropriate given the nature of my
> > question.
>
> > I'm working on an open source code library to help automate and clean
> > up parameter validation code. It's almost ready to go into open beta.
> > But one last little glitch is holding me up, and that would be the
> > name of the factory class that serves as the entry point into the
> > library: Validate.
>
> > Essentially, when you invoke the methods in this thing, your code
> > looks like this:
>
> > Validate.That(foo,
> > "foo").IsNotNull().StartsWith("bar").EndsWith("baz")
>
> > This works beautifully so far, but it becomes problematic when you use
> > it from ASP.NET pages, where a Validate method is already defined. As
> > you can imagine, the compiler thinks you're trying to invoke the
> > Validate method on the page; so invoking one of the That methods on
> > the Validate class (a factory) makes no sense.
>
> > You can get around it by using an alias with the namespace and change
> > to Verify or something:
>
> > using NValidate.Framework.Validate = Verify;
>
> > However, this creates a lot of manual work for the developer. It would
> > seem that the onus is on *me* as the publisher of the library to come
> > up with a solution. I mean, the whole POINT of this thing is to make
> > our lives easier.
>
> > So here's what I'm thinking: I could change the name of the Validate
> > class to Verify. That gets around the whole problem with ASP.NET
> > pages. That leaves only the following real concerns:
>
> > 1.) Verify, like Validate before it, is a *very* common word. It's
> > likely that it will conflict with existing method names.
>
> > 2.) The product name is NValidate. (Yep, just like NUnit, NCover,
> > NAnt, etc.) There might be a perceived disconnect between the product
> > name and the primary entry point into the library itself. (Validate
> > vs. Verify.)
>
> > 3.) The classes that validate parameters are called validators. Again,
> > it's the same disconnect.
>
> > My questions for you folks with far greater experience than myself
> > are:
>
> > 1.) Is the difference between the product name and the method name
> > that critical?
>
> > 2.) Is there a better way to name the factory class?
>
> > I'm pretty desperate for input here as this is a one-man project so
> > far. Any help you big brained-folks can provide will be greatly
> > appreciated. For those who are interested, I can provide links to the
> > materials and the source code under development. (I won't spam the
> > boards--I'm not marketing something here. I'm trying to solve a
> > problem, and I don't know the best way to do it.)
>
> > Again, thanks for your help.- Hide quoted text -
>
> - Show quoted text -

Actually, the source code itself is pretty explicit. The API, however,
provides an implementation of fluent interfaces.

For example, here are some of the class names in the
NValidate.Framework namespace:

ValidatorBase
ValueTypeValidatorBase (derives from ValidatorBase)
ObjectValidatorBase (derives from ValidatorBase)
BooleanValidator (derives from ValueTypeValidatorBase)
StringValidator (derives from ObjectValidatorBase)
ArrayValidator (derives from ObjectValidatorBase)
ConnectionValidator (derives from ObjectValidatorBase)

The method names on the validator classes are designed to help you
validate parameters using a clean, simple interface. The idea was born
out of refactoring and unit testing. (In other words, I ripped off
NUnit's Assert.That interface to refactor my parameter validation
code.)

The idea is that you write this:

Validate.That(foo, "foo").IsNotNullOrEmpty();

Instead of this:

if (null == foo)
throw new ArgumentNullException("foo");
if (string.Empty == foo)
throw new ArgumentException("Empty strings not permitted.", "foo");

Validate and Verify are both very common words and could easily cause
conflicts (as you noticed) and also don't really portray exactly what
is being validated.

I think NValidate would be a good choice (especially since "nv" is
very unique in intellisense and easy to type).

Normally I believe that classes should be nouns but I see where you're
going with the constraint type language, similar to the new NUnit
stuff, so using a verb here is fine in my opinion.

Sam


------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.


On Thu, 11 Oct 2007 17:59:41 -0000, Mike Hofer <kchighland@gmail.com>
wrote:

>Please forgive the cross-post to multiple forums. I did it
>intentionally, but I *think* it was appropriate given the nature of my
>question.
>
>
>Again, thanks for your help.

On Oct 11, 3:02 pm, Samuel R. Neff <samueln...@nomail.com> wrote:
> Validate and Verify are both very common words and could easily cause
> conflicts (as you noticed) and also don't really portray exactly what
> is being validated.

Agreed.

However, the library is well documented (both internally and
externally) so that it shouldn't be difficult to understand. Anyone
familiar with NUnit should be able to figure out what NValidate code
is doing relatively quickly.

> > I think NValidate would be a good choice (especially since "nv" is
> very unique in intellisense and easy to type).

It would, indeed, except that it would require an intentional
deviation from a naming standard. Then again, if that deviation is
well-documented, and for a well-thought out reason, it's acceptable.

> Normally I believe that classes should be nouns but I see where you're
> going with the constraint type language, similar to the new NUnit
> stuff, so using a verb here is fine in my opinion.

There is a precedent: the Assert class in NUnit. The big difference
between NUnit and NValidate, I think, is that NValidate implements
fluent interfaces to optimize its performance. Since NValidate might
perform multiple tests on a single parameter, and the tests are
encapsulated in a validator object, I didn't want to have to recreate
the validator object over and over again; so the validation methods
return a reference to the validator itself (unless, of course, one of
them fails, in which case it throws an exception).

> Sam

Thank you for your input!

Mike,

Here is another thought. Why not use a class with a static member
Validate and then have an internal class, or singleton hanging off the
parent class, like so:

NValidate.Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");

It would require one level of indirection, but it could be seen as an
entry point into the syntax you want.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"Mike Hofer" <kchighland@gmail.com> wrote in message
news:1192130388.508010.113350@57g2000hsv.googlegroups.com...
> On Oct 11, 3:02 pm, Samuel R. Neff <samueln...@nomail.com> wrote:
>> Validate and Verify are both very common words and could easily cause
>> conflicts (as you noticed) and also don't really portray exactly what
>> is being validated.
>
> Agreed.
>
> However, the library is well documented (both internally and
> externally) so that it shouldn't be difficult to understand. Anyone
> familiar with NUnit should be able to figure out what NValidate code
> is doing relatively quickly.
>
>> > I think NValidate would be a good choice (especially since "nv" is
>> very unique in intellisense and easy to type).
>
> It would, indeed, except that it would require an intentional
> deviation from a naming standard. Then again, if that deviation is
> well-documented, and for a well-thought out reason, it's acceptable.
>
>> Normally I believe that classes should be nouns but I see where you're
>> going with the constraint type language, similar to the new NUnit
>> stuff, so using a verb here is fine in my opinion.
>
> There is a precedent: the Assert class in NUnit. The big difference
> between NUnit and NValidate, I think, is that NValidate implements
> fluent interfaces to optimize its performance. Since NValidate might
> perform multiple tests on a single parameter, and the tests are
> encapsulated in a validator object, I didn't want to have to recreate
> the validator object over and over again; so the validation methods
> return a reference to the validator itself (unless, of course, one of
> them fails, in which case it throws an exception).
>
>> Sam
>
> Thank you for your input!
>

On Oct 11, 3:31 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> Mike,
>
> Here is another thought. Why not use a class with a static member
> Validate and then have an internal class, or singleton hanging off the
> parent class, like so:
>
> NValidate.Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz");
>
> It would require one level of indirection, but it could be seen as an
> entry point into the syntax you want.
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - m...@spam.guard.caspershouse.com
>
> "Mike Hofer" <kchighl...@gmail.com> wrote in message
>
> news:1192130388.508010.113350@57g2000hsv.googlegroups.com...
>
>
>
> > On Oct 11, 3:02 pm, Samuel R. Neff <samueln...@nomail.com> wrote:
> >> Validate and Verify are both very common words and could easily cause
> >> conflicts (as you noticed) and also don't really portray exactly what
> >> is being validated.
>
> > Agreed.
>
> > However, the library is well documented (both internally and
> > externally) so that it shouldn't be difficult to understand. Anyone
> > familiar with NUnit should be able to figure out what NValidate code
> > is doing relatively quickly.
>
> >> > I think NValidate would be a good choice (especially since "nv" is
> >> very unique in intellisense and easy to type).
>
> > It would, indeed, except that it would require an intentional
> > deviation from a naming standard. Then again, if that deviation is
> > well-documented, and for a well-thought out reason, it's acceptable.
>
> >> Normally I believe that classes should be nouns but I see where you're
> >> going with the constraint type language, similar to the new NUnit
> >> stuff, so using a verb here is fine in my opinion.
>
> > There is a precedent: the Assert class in NUnit. The big difference
> > between NUnit and NValidate, I think, is that NValidate implements
> > fluent interfaces to optimize its performance. Since NValidate might
> > perform multiple tests on a single parameter, and the tests are
> > encapsulated in a validator object, I didn't want to have to recreate
> > the validator object over and over again; so the validation methods
> > return a reference to the validator itself (unless, of course, one of
> > them fails, in which case it throws an exception).
>
> >> Sam
>
> > Thank you for your input!- Hide quoted text -
>
> - Show quoted text -

I'm thinking about this suggestion, because it has merit. But I'm
wondering if this isn't possible just using namespace resolution.

Thoughts?

On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gmail.com> wrote:
> Please forgive the cross-post to multiple forums. I did it
> intentionally, but I *think* it was appropriate given the nature of my
> question.
>
> I'm working on an open source code library to help automate and clean
> up parameter validation code. It's almost ready to go into open beta.
> But one last little glitch is holding me up, and that would be the
> name of the factory class that serves as the entry point into the
> library: Validate.
>
> Essentially, when you invoke the methods in this thing, your code
> looks like this:
>
> Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz")
>
> This works beautifully so far, but it becomes problematic when you use
> it from ASP.NET pages, where a Validate method is already defined. As
> you can imagine, the compiler thinks you're trying to invoke the
> Validate method on the page; so invoking one of the That methods on
> the Validate class (a factory) makes no sense.
>
> You can get around it by using an alias with the namespace and change
> to Verify or something:
>
> using NValidate.Framework.Validate = Verify;
>
> However, this creates a lot of manual work for the developer. It would
> seem that the onus is on *me* as the publisher of the library to come
> up with a solution. I mean, the whole POINT of this thing is to make
> our lives easier.
>
> So here's what I'm thinking: I could change the name of the Validate
> class to Verify. That gets around the whole problem with ASP.NET
> pages. That leaves only the following real concerns:
>
> 1.) Verify, like Validate before it, is a *very* common word. It's
> likely that it will conflict with existing method names.
>
> 2.) The product name is NValidate. (Yep, just like NUnit, NCover,
> NAnt, etc.) There might be a perceived disconnect between the product
> name and the primary entry point into the library itself. (Validate
> vs. Verify.)
>
> 3.) The classes that validate parameters are called validators. Again,
> it's the same disconnect.
>
> My questions for you folks with far greater experience than myself
> are:
>
> 1.) Is the difference between the product name and the method name
> that critical?
>
> 2.) Is there a better way to name the factory class?
>
> I'm pretty desperate for input here as this is a one-man project so
> far. Any help you big brained-folks can provide will be greatly
> appreciated. For those who are interested, I can provide links to the
> materials and the source code under development. (I won't spam the
> boards--I'm not marketing something here. I'm trying to solve a
> problem, and I don't know the best way to do it.)
>
> Again, thanks for your help.

Neat concept by the way.

I agree that this is a case where a verb name actually makes more
sense. But, along the same lines as Nicholas' suggestion and using a
noun-verb combination...

Validator.Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");

or

Validator.Demand.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");

....where Validator is a static class and Validate or Demand is a
singleton.