Method Name Suggestion: Validate a Poor Choice?

[Mike Hofer]

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(f oo,
"foo").IsNotNul l().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.Frame work.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.

[IfThenElse]

Call it nValidate

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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.

[clintonG]

Be more explicit with your naming, FactoryClassVal idation,
CleanMyRoomVali dation 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" <kc********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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.

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard. caspershouse.co m

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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 Hofer]

On Oct 11, 2:27 pm, "clintonG" <nob...@nowhere .comwrote:

Be more explicit with your naming, FactoryClassVal idation,
CleanMyRoomVali dation 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://clintongallaghe r.metromilwauke e.com/

"Mike Hofer" <kchighl...@gma il.comwrote in message

news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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.Frame work namespace:

ValidatorBase
ValueTypeValida torBase (derives from ValidatorBase)
ObjectValidator Base (derives from ValidatorBase)
BooleanValidato r (derives from ValueTypeValida torBase)
StringValidator (derives from ObjectValidator Base)
ArrayValidator (derives from ObjectValidator Base)
ConnectionValid ator (derives from ObjectValidator Base)

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(f oo, "foo").IsNotNul lOrEmpty();

Instead of this:

if (null == foo)
throw new ArgumentNullExc eption("foo");
if (string.Empty == foo)
throw new ArgumentExcepti on("Empty strings not permitted.", "foo");

[Samuel R. Neff]

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 <kc********@gma il.com>
wrote:

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

[Brian Gideon]

On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.comwrote:

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(f oo,
"foo").IsNotNul l().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.Frame work.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.Valid ate.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

or

Validator.Deman d.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

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

[Mike Hofer]

On Oct 11, 4:15 pm, Brian Gideon <briangid...@ya hoo.comwrote:

On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.comwrote:

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(f oo,
"foo").IsNotNul l().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.Frame work.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.

Thanks. :)

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.Valid ate.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

or

Validator.Deman d.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

...where Validator is a static class and Validate or Demand is a
singleton.- Hide quoted text -

I *really* like Demand as a method name. If I had to change the verb,
Demand.That() is really nice. It's nominally shorter, and it's a stong
word (stronger than Validate, in my opinion). (I'm always looking for
ways to write less code, not more. Fewer characters is a good thing,
so long as it doesn't sacrifice code clarity or quality.)

If I had to choose a noun to prefix it with, I think I'd want
something equally as strong. What about ParamRule?

ParamRule.Deman d.That()

This has the advantage of making it clear that we're working with
parameters. So we end up with this:

ParamRule.Deman d.That(foo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

instead of this:

Validate.That(f oo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

>From a C# perspective, that's fine; VB developers might balk at it.

Thoughts? Suggestions?

[IfThenElse]

How about,

ThouShell.beEqu alTo().NotBeNul l().StartsWith( "bar").EndsWith ("baz");

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ o80g2000hse.goo glegroups.com.. .

On Oct 11, 4:15 pm, Brian Gideon <briangid...@ya hoo.comwrote:

>On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.comwrote:

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(f oo,
"foo").IsNotNul l().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.Frame work.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.

Thanks. :)

>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.Vali date.That(foo,
"foo").IsNotNu ll().StartsWith ("bar").EndsWit h("baz");

or

Validator.Dema nd.That(foo,
"foo").IsNotNu ll().StartsWith ("bar").EndsWit h("baz");

...where Validator is a static class and Validate or Demand is a
singleton.- Hide quoted text -

I *really* like Demand as a method name. If I had to change the verb,
Demand.That() is really nice. It's nominally shorter, and it's a stong
word (stronger than Validate, in my opinion). (I'm always looking for
ways to write less code, not more. Fewer characters is a good thing,
so long as it doesn't sacrifice code clarity or quality.)

If I had to choose a noun to prefix it with, I think I'd want
something equally as strong. What about ParamRule?

ParamRule.Deman d.That()

This has the advantage of making it clear that we're working with
parameters. So we end up with this:

ParamRule.Deman d.That(foo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

instead of this:

Validate.That(f oo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

>>From a C# perspective, that's fine; VB developers might balk at it.

Thoughts? Suggestions?

[Scott M.]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:um******** ******@TK2MSFTN GP02.phx.gbl...

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 agree and I believe it's better OO to do so. Classes get noun names,
methods get verb names, properties get adjective names, and events get
verb/tense names (ie. Validated, Validating).

Ultimately, someone has to use your API and the more intuitive your
classes/class member names are the less chance the API will be used
incorrectly.

-Scott M.