我正在读一本书，其中断言（双关语）"无论条件是真还是假，都应该用Debug.Assert方法加载代码。"
我还没有使用过这两种调试方法，但它有一定的意义。然而，我讨厌在我的生产代码库中到处都是这些东西。
想法？
这很好，因为编译器在发布版本中省略了它。这是一个不错的做法，您不需要从源代码中删除它们（实际上，您可能不应该）。但是您必须小心：
Debug.Assert(SomethingImportantThatMustExecute());
是坏-SomethingImportantThatMustExecute将在发布时被忽略；您必须使用：
bool result = SomethingImportantThatMustExecute()
Debug.Assert(result);
基本上，要避免对条件方法和分部方法的调用产生副作用。
这取决于您使用它的目的。如果你在自己的方法中使用它来进行断言，为了确保它们正常工作，我认为可以，但我更喜欢单元测试来验证我能想到的一切。
使用它来验证传入输入（例如参数）不是一个好主意（IMO）。在这种情况下，我相信以正常方式使用异常会更加一致：
if (foo == null)
{
throw new ArgumentNullException("foo");
}
在我看来，这种行为应该而不是仅仅因为您正在运行发布代码而改变。
如果编译Release版本（使用Visual Studio项目设置），则所有Debug.Assert语句都将自动删除。所以，是的，要大量使用它们。
是的，断言是可以的。请注意，它们不仅是逻辑检查（这是显而易见的），而且还是一种文档形式，比注释更可靠。
但一定要事先考虑单元测试。如果要测试Debug构建，结果（关于错误逻辑）可能与发布版本不同。
对于希望在Release构建中处于活动状态的检查，可以使用Trace.Assert（）.
还没有人提到代码契约，这是一种更丰富、更结构化的检查和记录代码的方式。
您可以在生产代码库中自由使用Debug.Assert。CCD_ 5用CCD_。如果您在"realease"配置中编译代码，编译器将跳过调用Debug.Assert。