为什么使用#if 0作为块注释输出？

Question

反向工程代码，我有点震惊的风格，但我想确保没有好的理由去做这些事情.

是只有我吗，还是这是一种可怕的编码风格？

if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

以及为什么不打算将代码包装在

#if 0
....
#endif

而不是评论？

编辑:因此，正如下面所解释的，这是因为可能会出现flummox /* */，我没有意识到这一点。

但我还是不明白，为什么不直接使用编程环境工具或最喜欢的文本编辑器的宏来阻止使用"//“进行注释

这难道不是更直截了当，更容易理解的视觉跳过吗？

难道我只是对C缺乏经验，并且不知道为什么这些事情可能是个好主意--或者没有任何借口，我有理由对这段代码有多么的丑陋感到恼火吗？

Answer 1

当删除的块包含块注释时，#if 0非常频繁地使用。

我不会说这是一个好的练习，但我经常看到它。

单行流控制+语句很容易理解，尽管我个人避免使用它(而且我所使用的大多数编码准则都禁止它)。

顺便说一下，我可能会把标题编辑得有点有用：“为什么要使用#if 0而不是块注释”

如果您有以下内容

#if 0
        silly();
        if(foo)
           bar();
        /* baz is a flumuxiation */
        baz = fib+3;
#endif

如果您天真地将#if 0/#endif替换为/* */，这将导致注释在flumuxiation之后立即结束，当您按下*/代替上面的#endif时，会导致语法错误。

编辑:最后一个注意事项是，开发时通常只使用#if 0语法，特别是当您必须支持多个版本或依赖关系或硬件平台时。代码被修改为

#ifdef _COMPILED_WITHOUT_FEATURE_BAZ_
    much_code();
#endif

使用集中的标头定义(或不定义)数百个这些#定义常量。这不是世界上最漂亮的事情，但每次我在一个规模可观的项目上工作时，我们都会使用一些运行时开关、编译时常量(this)、编译时编译决策(只需根据版本使用不同的..cpp)以及偶尔的模板解决方案。这一切都取决于细节。

虽然你是开发人员，但首先要让它正常工作.如果您不确定旧代码是否仍然有价值，那么#if 0是非常常见的。

Answer 2

评论就是评论。他们描述了密码。

被排除在编译之外的代码是代码，而不是注释。它通常会包含一些注释，这些注释描述了目前尚未编译的代码。

它们是两个截然不同的概念，我认为强制使用相同的语法是一个错误。

我编辑这个是因为我正在进行一个大规模的重构，并且我正在大量使用这个模式。

作为此重构的一部分，我将删除一些广泛使用的类型，并将它们替换为另一个类型。其结果，当然，是什么都不会建立。

我真的讨厌花几天时间来解决一个又一个问题，希望当我做完之后，一切都会建立起来，所有的测试都会运行。

因此，我的第一步是#ifdef-出所有不能编译的代码，然后忽略调用它的所有单元测试。这样做了，所有的构建和所有未被忽视的测试都通过了。

其结果是许多函数如下所示：

public void MyFunction()
{
#if true
    throw new NotImplementedException("JT-123");
#else
    // all the existing code that won't compile
#endif
}

然后我对单元测试进行了分类，一次一次，然后修复函数，一次一次。

我需要花几天的时间来完成所有这些，所有这些#if's都会消失，然后我才会创建这个合并请求，但是我发现在这个过程中它很有帮助。

Answer 3

除了C风格的注释不嵌套的问题外，如果使用支持代码折叠的编辑器，使用#if 0禁用代码块具有可以折叠的优点。这在任何编辑器中都是非常容易做到的，而如果没有编辑器支持/宏，使用C++样式的注释来禁用大型代码块可能会很困难。

而且，许多#if 0块也有一个else块。这提供了一种在两种实现/算法之间交换的简单方法，并且可以说比大量注释掉一个部分和不注释另一个部分更容易出错。但是，最好在这种情况下使用更易读的东西，如#if DEBUG。