代码之家 › 专栏 › 技术社区 › MatthewMartin muthu

与#if/#endif相比,条件属性的缺点是什么?

conditional-attribute c#

2

MatthewMartin muthu · 技术社区 · 14 年前

我的代码库有很多 #if DEBUG/#endif

[Conditional("DEBUG")]
public void CheckFontSizeMath()
{
  //This check must not block SellSnakeOil() in production, even if it fails.
  if(perferredSize+increment!=increment+preferredSize)
    throw new WeAreInAnUnexpectedParallelUniverseException();
}

我会后悔把这些都改成新的做事方式吗?

更新 :我在寻找两种相似但不同的语法样式的特征之间的差异。我知道有很多其他的方法来演示应用程序的工作,我也这样做。我不准备完全放弃断言。

此外,我还为一个实际的调试版本只更新了方法名。

4 回复 | 直到 14 年前

1

3

Hans Passant 14 年前

这样做没问题。更流行的方法是使用 Code Contracts .

2

joshperry 14 年前

一旦你测试了你的代码,你就可以随心所欲地重构代码。

没有测试的代码,即使是昨天写的,也是遗留代码。。。 Working Effectively with Legacy Code ,这是一本管理遗留代码的了不起的书;32篇评论,5颗星。

3

1

Dirk Vollmar 14 年前

您可以选择使用Hans建议的代码契约,或者使用 System.Diagnostics.Debug

Debug.Assert(1 + 1 == 2, "Math went wrong!");

生成发布版本时,将自动删除此检查。

4

1

Mark Simpson 14 年前

它不如独立于构建配置的硬检查和异常那样健壮。考虑到大多数代码都应该在发布模式下处理错误,这是一个好主意。
在调用站点,不明显正在调用条件方法。您只需看到“DoSomething();”。我更喜欢通过一个约定来命名我的条件方法,我知道它是一个条件;例如DEBUG\u SanityCheckBufferContents()。

简而言之,我的经验法则是:

清楚地命名条件方法
Pragma#if out方法体中的代码