这有点过分吗？ [英] Is This Overkill?

问题描述

我一直在维护一些源代码，我注意到代码中有一些激进的

不一致，特别是参数的验证方式

验证了。我注意到这在我的整个职业生涯中几乎都是

案例。


例如，请考虑以下块：


如果siteId< = 0那么

抛出新的ArgumentOutOfRangeException（" siteId"）

结束如果

如果名称是Nothing那么

抛出新的ArgumentNullException（" name"）

结束如果

如果name = String.Empty那么

抛出新的ArgumentException（不允许空字符串。，

" name"）

结束如果

如果buildingIdToIgnore< -1然后

抛出新的ArgumentOutOfRangeException（" buildingIdToIgnore"）

结束如果


有时，此代码折叠如下：


如果siteId< = 0则抛出新的

ArgumentOutOfRangeException（" siteId"）

如果名称为Nothing Then抛出新的ArgumentNullException（" name"）

如果name = String.Empty则抛出新的ArgumentException（不允许使用空的

如果buildingIdToIgnore< -1然后扔掉新的

ArgumentOutOfRangeException（" buildingIdToIgnore"）


有时候，它完全被省略了。有时候，并不是所有的过程的

参数都经过验证。在许多情况下，

消息从一个参数验证到下一个参数验证都不一致。

（资源文件将大大有助于解决这个问题，但是''

完全不同的主题。）


我一直在思考的是一种让它更容易的方法

验证方法参数。我的*理论*就是它写了很多粗犷的

代码如果...然后......扔...结束如果，这会导致捷径

，最终，彻底遗漏。因此，缩小它和

的方法使代码更清晰可能有助于鼓励一致使用

参数验证，这应该（理论上）提高代码质量
整个系统。


所以我有这个模型我正在努力，在我完全关闭之前

深度结束有了它，我以为我会帮你看看你想要的是什么。


基本上，它是基于NUnit声称要一致且清楚地验证参数

。所以，上面的代码更改为：


Validate.That（siteId，" siteId"）。IsNotNegative（）

Validate.That（name ，名称.IsNotNullOrEmpty（）

Validate.That（buildingIdToIgnore，

" buildingIdToIgnore"）。IsGreaterThan（-2）

验证。那（连接）.IsOpenAndIsNotNull（）


我对模型的测试进展顺利。我认为，一旦我得到了它，它可以提供一个非常酷的，可扩展的验证框架

参数。 框架在一个单独的类库中，并且消息在字符串资源文件中是
，提供一致性。


当然，最重要的警告是那里'并不保证它解决了*执行*问题。还有一个问题，FxCop认为

当我没有验证参数时。


所以我的问题是，这是甚至值得做什么？当现有的

代码库被重构以使用它时，它看起来更清晰，并且更容易阅读和维护，并且显示为

。但问题仍然存在：这是一个真正的问题吗？或者我是否解决了一个并不存在的问题？


您的意见非常感谢。


谢谢！

I''ve been maintaining some source code, and I''ve noticed some radical
inconsistency in the code, particularly in the way that parameters are
validated. I''ve noticed that this seems to have been pretty much the
case throughout my career.

For instance, consider the following block:

If siteId <= 0 Then
Throw New ArgumentOutOfRangeException("siteId")
End If
If name Is Nothing Then
Throw New ArgumentNullException("name")
End If
If name = String.Empty Then
Throw New ArgumentException("Empty strings are not permitted.",
"name")
End If
If buildingIdToIgnore < -1 Then
Throw New ArgumentOutOfRangeException("buildingIdToIgnore")
End If

Sometimes, this code is collapsed as follows:

If siteId <= 0 Then Throw New
ArgumentOutOfRangeException("siteId")
If name Is Nothing Then Throw New ArgumentNullException("name")
If name = String.Empty Then Throw New ArgumentException("Empty
strings are not permitted.", "name")
If buildingIdToIgnore < -1 Then Throw New
ArgumentOutOfRangeException("buildingIdToIgnore")

Sometimes, it''s omitted altogether. Somtimes, not all of the
parameters to the procedure are validated. And in many cases, the
messages aren''t consistent from one parameter validation to the next.
(Resource files would go a long way towards solving that, but that''s a
whole different thread.)

What I''ve been pondering for some time is a way to make it easier to
validate method parameters. My *theory* is that it''s a lot of gangly
code to write If...Then...Throw...End If, which leads to short-cuts
and, eventually, outright omissions. So, a way to abbreviate that and
make the code clearer might help to encourage consistent use of
parameter validation, which should (in theory) improve code quality
throughout the system.

So I have this model I''m working on, and before I go completely off
the deep end with it, I thought I''d run it by you to see what you
thought of it.

Essentially, it''s based on NUnit asserts to validate parameters
consistently and clearly. So, the code above is changed to this:

Validate.That(siteId, "siteId").IsNotNegative()
Validate.That(name, "name").IsNotNullOrEmpty()
Validate.That(buildingIdToIgnore,
"buildingIdToIgnore").IsGreaterThan(-2)
Validate.That(connection).IsOpenAndIsNotNull()

My tests for the model are going very well. I think that once I get it
going, it could provide a very cool, extensible validation framework
for parameters. The "framework" is in a separate class library, and
the messages are in a string resource file, providing consistency.

The big caveat, of course, is that there''s no guarantee that it solves
the *enforcement* problem. There''s also the problem that FxCop thinks
I''m not validating parameters when I am.

So the question I have is, is this even worth doing? When an existing
code base is refactored to use it, it looks much cleaner, and appears
to be easier to read and maintain. But the question remains: is this a
real problem, or am I addressing an issue that doesn''t really exist?

Your input is greatly appreciated.

Thanks!

推荐答案

我很想看到其他人''回答这个问题，但这里是我的

I will be very interested to see others'' responses to this, but here''s my

.02。


尽管做起来并不总是切实可行或不合适所以，这个

性质的任务最好通过数据库进行管理。


是的，我要留下一个没有说明这句话的山，最值得注意的是

回答问题如何，但我会推荐这个想法和

面向方面的编程给你进一步研究。


Paul


" Mike Hofer" < kc ******** @ gmail.com写信息

新闻：11 ********************** @ l77g2000hsb.googlegr oups.com ...

.02.

While it is not always practicable or appropriate to do so, tasks of this
nature are best managed with a database.

Yes, I''m leaving a mountain unsaid with this statement, most notably
answering the question "how", but I would recommend this idea and
aspect-oriented programming to you for further study.

Paul

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...

我一直在维护一些源代码，我注意到了一些激进的

代码中的不一致，特别是参数的验证方式。我注意到这在我的整个职业生涯中几乎都是

案例。


例如，请考虑以下块：


如果siteId< = 0那么

抛出新的ArgumentOutOfRangeException（" siteId"）

结束如果

如果名称是Nothing那么

抛出新的ArgumentNullException（" name"）

结束如果

如果name = String.Empty那么

抛出新的ArgumentException（不允许空字符串。，

" name"）

结束如果

如果buildingIdToIgnore< -1然后

抛出新的ArgumentOutOfRangeException（" buildingIdToIgnore"）

结束如果


有时，此代码折叠如下：


如果siteId< = 0则抛出新的

ArgumentOutOfRangeException（" siteId"）

如果名称为Nothing Then抛出新的ArgumentNullException（" name"）

如果name = String.Empty则抛出新的ArgumentException（不允许使用空的

如果buildingIdToIgnore< -1然后扔掉新的

ArgumentOutOfRangeException（" buildingIdToIgnore"）


有时候，它完全被省略了。有时候，并不是所有的过程的

参数都经过验证。在许多情况下，

消息从一个参数验证到下一个参数验证都不一致。

（资源文件将大大有助于解决这个问题，但是''

完全不同的主题。）


我一直在思考的是一种让它更容易的方法

验证方法参数。我的*理论*就是它写了很多粗犷的

代码如果...然后......扔...结束如果，这会导致捷径

，最终，彻底遗漏。因此，缩小它和

的方法使代码更清晰可能有助于鼓励一致使用

参数验证，这应该（理论上）提高代码质量
整个系统。


所以我有这个模型我正在努力，在我完全关闭之前

深度结束有了它，我以为我会帮你看看你想要的是什么。


基本上，它是基于NUnit声称要一致且清楚地验证参数

。所以，上面的代码更改为：


Validate.That（siteId，" siteId"）。IsNotNegative（）

Validate.That（name ，名称.IsNotNullOrEmpty（）

Validate.That（buildingIdToIgnore，

" buildingIdToIgnore"）。IsGreaterThan（-2）

验证。那（连接）.IsOpenAndIsNotNull（）


我对模型的测试进展顺利。我认为，一旦我得到了它，它可以提供一个非常酷的，可扩展的验证框架

参数。 框架在一个单独的类库中，并且消息在字符串资源文件中是
，提供一致性。


当然，最重要的警告是那里'并不保证它解决了*执行*问题。还有一个问题，FxCop认为

当我没有验证参数时。


所以我的问题是，这是甚至值得做什么？当现有的

代码库被重构以使用它时，它看起来更清晰，并且更容易阅读和维护，并且显示为

。但问题仍然存在：这是一个真正的问题吗？或者我是否解决了一个并不存在的问题？


您的意见非常感谢。


谢谢！

I''ve been maintaining some source code, and I''ve noticed some radical
inconsistency in the code, particularly in the way that parameters are
validated. I''ve noticed that this seems to have been pretty much the
case throughout my career.

For instance, consider the following block:

If siteId <= 0 Then
Throw New ArgumentOutOfRangeException("siteId")
End If
If name Is Nothing Then
Throw New ArgumentNullException("name")
End If
If name = String.Empty Then
Throw New ArgumentException("Empty strings are not permitted.",
"name")
End If
If buildingIdToIgnore < -1 Then
Throw New ArgumentOutOfRangeException("buildingIdToIgnore")
End If

Sometimes, this code is collapsed as follows:

If siteId <= 0 Then Throw New
ArgumentOutOfRangeException("siteId")
If name Is Nothing Then Throw New ArgumentNullException("name")
If name = String.Empty Then Throw New ArgumentException("Empty
strings are not permitted.", "name")
If buildingIdToIgnore < -1 Then Throw New
ArgumentOutOfRangeException("buildingIdToIgnore")

Sometimes, it''s omitted altogether. Somtimes, not all of the
parameters to the procedure are validated. And in many cases, the
messages aren''t consistent from one parameter validation to the next.
(Resource files would go a long way towards solving that, but that''s a
whole different thread.)

What I''ve been pondering for some time is a way to make it easier to
validate method parameters. My *theory* is that it''s a lot of gangly
code to write If...Then...Throw...End If, which leads to short-cuts
and, eventually, outright omissions. So, a way to abbreviate that and
make the code clearer might help to encourage consistent use of
parameter validation, which should (in theory) improve code quality
throughout the system.

So I have this model I''m working on, and before I go completely off
the deep end with it, I thought I''d run it by you to see what you
thought of it.

Essentially, it''s based on NUnit asserts to validate parameters
consistently and clearly. So, the code above is changed to this:

Validate.That(siteId, "siteId").IsNotNegative()
Validate.That(name, "name").IsNotNullOrEmpty()
Validate.That(buildingIdToIgnore,
"buildingIdToIgnore").IsGreaterThan(-2)
Validate.That(connection).IsOpenAndIsNotNull()

My tests for the model are going very well. I think that once I get it
going, it could provide a very cool, extensible validation framework
for parameters. The "framework" is in a separate class library, and
the messages are in a string resource file, providing consistency.

The big caveat, of course, is that there''s no guarantee that it solves
the *enforcement* problem. There''s also the problem that FxCop thinks
I''m not validating parameters when I am.

So the question I have is, is this even worth doing? When an existing
code base is refactored to use it, it looks much cleaner, and appears
to be easier to read and maintain. But the question remains: is this a
real problem, or am I addressing an issue that doesn''t really exist?

Your input is greatly appreciated.

Thanks!

" Mike Hofer" ; < kc ******** @ gmail.com写信息

新闻：11 ********************** @ l77g2000hsb.googlegr oups.com ...

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...

我一直在维护一些源代码，我注意到了一些激进的

代码中的不一致，特别是参数的验证方式。我注意到这在我的整个职业生涯中几乎都是

案例。


例如，请考虑以下块：


如果siteId< = 0那么

抛出新的ArgumentOutOfRangeException（" siteId"）

结束如果

如果名称是Nothing那么

抛出新的ArgumentNullException（" name"）

结束如果

如果name = String.Empty那么

抛出新的ArgumentException（不允许空字符串。，

" name"）

结束如果

如果buildingIdToIgnore< -1然后

抛出新的ArgumentOutOfRangeException（" buildingIdToIgnore"）

结束如果


有时，此代码折叠如下：


如果siteId< = 0则抛出新的

ArgumentOutOfRangeException（" siteId"）

如果名称为Nothing Then抛出新的ArgumentNullException（" name"）

如果name = String.Empty则抛出新的ArgumentException（不允许使用空的

如果buildingIdToIgnore< -1然后扔掉新的

ArgumentOutOfRangeException（" buildingIdToIgnore"）


有时候，它完全被省略了。有时候，并不是所有的过程的

参数都经过验证。在许多情况下，

消息从一个参数验证到下一个参数验证都不一致。

（资源文件将大大有助于解决这个问题，但是''

完全不同的主题。）


我一直在思考的是一种让它更容易的方法

验证方法参数。我的*理论*就是它写了很多粗犷的

代码如果...然后......扔...结束如果，这会导致捷径

，最终，彻底遗漏。因此，缩小它和

的方法使代码更清晰可能有助于鼓励一致使用

参数验证，这应该（理论上）提高代码质量
整个系统。


所以我有这个模型我正在努力，在我完全关闭之前

深度结束有了它，我以为我会帮你看看你想要的是什么。


基本上，它是基于NUnit声称要一致且清楚地验证参数

。所以，上面的代码更改为：


Validate.That（siteId，" siteId"）。IsNotNegative（）

Validate.That（name ，名称.IsNotNullOrEmpty（）

Validate.That（buildingIdToIgnore，

" buildingIdToIgnore"）。IsGreaterThan（-2）

验证。那（连接）.IsOpenAndIsNotNull（）


我对模型的测试进展顺利。我认为，一旦我得到了它，它可以提供一个非常酷的，可扩展的验证框架

参数。 框架在一个单独的类库中，并且消息在字符串资源文件中是
，提供一致性。


当然，最重要的警告是那里'并不保证它解决了*执行*问题。还有一个问题，FxCop认为

当我没有验证参数时。


所以我的问题是，这是甚至值得做什么？当现有的

代码库被重构以使用它时，它看起来更清晰，并且更容易阅读和维护，并且显示为

。但问题仍然存在：这是一个真正的问题吗？或者我是否解决了一个并不存在的问题？


您的意见非常感谢。


谢谢！

I''ve been maintaining some source code, and I''ve noticed some radical
inconsistency in the code, particularly in the way that parameters are
validated. I''ve noticed that this seems to have been pretty much the
case throughout my career.

For instance, consider the following block:

If siteId <= 0 Then
Throw New ArgumentOutOfRangeException("siteId")
End If
If name Is Nothing Then
Throw New ArgumentNullException("name")
End If
If name = String.Empty Then
Throw New ArgumentException("Empty strings are not permitted.",
"name")
End If
If buildingIdToIgnore < -1 Then
Throw New ArgumentOutOfRangeException("buildingIdToIgnore")
End If

Sometimes, this code is collapsed as follows:

If siteId <= 0 Then Throw New
ArgumentOutOfRangeException("siteId")
If name Is Nothing Then Throw New ArgumentNullException("name")
If name = String.Empty Then Throw New ArgumentException("Empty
strings are not permitted.", "name")
If buildingIdToIgnore < -1 Then Throw New
ArgumentOutOfRangeException("buildingIdToIgnore")

Sometimes, it''s omitted altogether. Somtimes, not all of the
parameters to the procedure are validated. And in many cases, the
messages aren''t consistent from one parameter validation to the next.
(Resource files would go a long way towards solving that, but that''s a
whole different thread.)

What I''ve been pondering for some time is a way to make it easier to
validate method parameters. My *theory* is that it''s a lot of gangly
code to write If...Then...Throw...End If, which leads to short-cuts
and, eventually, outright omissions. So, a way to abbreviate that and
make the code clearer might help to encourage consistent use of
parameter validation, which should (in theory) improve code quality
throughout the system.

So I have this model I''m working on, and before I go completely off
the deep end with it, I thought I''d run it by you to see what you
thought of it.

Essentially, it''s based on NUnit asserts to validate parameters
consistently and clearly. So, the code above is changed to this:

Validate.That(siteId, "siteId").IsNotNegative()
Validate.That(name, "name").IsNotNullOrEmpty()
Validate.That(buildingIdToIgnore,
"buildingIdToIgnore").IsGreaterThan(-2)
Validate.That(connection).IsOpenAndIsNotNull()

My tests for the model are going very well. I think that once I get it
going, it could provide a very cool, extensible validation framework
for parameters. The "framework" is in a separate class library, and
the messages are in a string resource file, providing consistency.

The big caveat, of course, is that there''s no guarantee that it solves
the *enforcement* problem. There''s also the problem that FxCop thinks
I''m not validating parameters when I am.

So the question I have is, is this even worth doing? When an existing
code base is refactored to use it, it looks much cleaner, and appears
to be easier to read and maintain. But the question remains: is this a
real problem, or am I addressing an issue that doesn''t really exist?

Your input is greatly appreciated.

Thanks!

我喜欢这个想法并且想过自己在某个时候做这个，只是

从未接触过它。


我可能会更进一步，并以某种方式将验证转移到引擎

方案类型的方法验证规则可能存储在XML文件中，然后参数将与它们的

函数名一起传递。这将为您提供一个存储规则的中心位置

什么是有效的，什么不是能够动态地改变

验证方案而不需要在需要时更改代码在

的未来。


它也可能，取决于它的架构，允许你更好地控制

规则值这可能依赖于传递给函数的其他值，而无需在代码体本身中创建一堆嵌套的

语句。


无论你做什么，执行它的使用总是会是一个问题。除非你在编码时站在肩膀或开发人员身上，否则

唯一真正的方法就是代码审查。

I like the idea and have thought about doing it myself at some point, just
never got around to it.

I might take it a bit further and somehow move the validation to an engine
scheme type of approach where rules for validation could be stored perhaps
in an XML file and then parameters would be passed in along with their
function names. This would give you a central location to store rules about
what is valid and what is not as well as the ability to perhaps alter
validation schemes dynamically without altering code if needed in the
future.

It may also, depending how it was architected, allow you to better control
rules for values that may be dependent upon other values that have been
passed into the function without having to create a bunch of nested
statements in the code body itself.

No matter what you do though, enforcement of its use is always going to be
an issue. Unless you stand over the shoulder or developers as they code, the
only real way to catch non-compliance would be code reviews.

这篇关于这有点过分吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！