C 宏/#define 缩进?

发布于 2024-08-13 20:05:35 字数 333 浏览 2 评论 0原文

我很好奇为什么我看到几乎所有 C 宏的格式都是这样的:

#ifndef FOO
#   define FOO
#endif

或者这样:

#ifndef FOO
#define FOO
#endif

但从来没有这样:

#ifndef FOO
    #define FOO
#endif

(此外,vim 的 = 运算符似乎只将前两个视为正确。)

这是吗由于编译器之间的可移植性问题,或者这只是一种标准做法?

I'm curious as to why I see nearly all C macros formatted like this:

#ifndef FOO
#   define FOO
#endif

Or this:

#ifndef FOO
#define FOO
#endif

But never this:

#ifndef FOO
    #define FOO
#endif

(moreover, vim's = operator only seems to count the first two as correct.)

Is this due to portability issues among compilers, or is it just a standard practice?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

风吹雪碎 2024-08-20 20:05:35

我已经看到它完成了所有三种方式,这似乎是风格问题,而不是语法问题

虽然通常第二个示例是最常见的,但我见过第一个(或第三个)用于帮助区分多个的情况#ifdefs 的级别。有时,逻辑可能会变得深度嵌套,一目了然地理解它的唯一方法是使用缩进,就像在 { 和 } 之间缩进代码块的常见做法一样。

I've seen it done all three ways, it seems to be a matter of style, not of syntax

While usually the second example is the most common, i've seen cases where the first (or third) is used to help distinguish multiple levels of #ifdefs. Sometimes the logic can become deeply nested and the only way to understand it at a glance is to use indentation much like it is common practice to indent blocks of code between { and }.

音盲 2024-08-20 20:05:35

IIRC,较旧的 C 预处理器要求 # 成为该行的第一个字符(尽管我从未真正遇到过有此要求的预处理器)。

我从来没有见过你的代码像你的第一个例子。我通常编写预处理器指令,如第二个示例所示。我发现它在视觉上对实际代码的缩进干扰较少(不再是我用 C 编写的)。

GNU C 预处理器手册说:

预处理指令是以下行
你的程序以“#”开头。
前后允许有空格
'#'。

IIRC, older C preprocessors required the # to be the first character on the line (though I've never actually encountered one that had this requirement).

I never seen your code like your first example. I usually wrote preprocessor directives as in your second example. I found that it visually interfered with the indentation of the actual code less (not that I write in C anymore).

The GNU C Preprocessor manual says:

Preprocessing directives are lines in
your program that start with '#'.
Whitespace is allowed before and after
the '#'.

囚你心 2024-08-20 20:05:35

作为优先选择,我使用第三种样式,但包含防护除外,我使用第二种样式。

我根本不喜欢第一种风格 - 我认为 #define 是一条预处理器指令,尽管实际上它当然不是,它后面是一个 #由预处理器指令define。但既然我确实这么想,把它们分开似乎是错误的。我希望提倡这种风格的人编写的文本编辑器将具有适用于以这种风格编写的代码的块缩进/取消缩进。但我不想使用没有的文本编辑器遇到它。

迎合古老的预处理器是没有意义的,其中 # 必须是该行的第一个字符,除非您还可以在头脑中列出这些实现与标准 C 之间的所有其他差异,以避免您遇到的其他问题他们可能不会支持这样做。当然,如果您确实正在使用预标准编译器,那就很公平了。

For preference I use the third style, with the exception of include guards, for which I use the second style.

I don't like the first style at all - I think of #define as being a preprocessor instruction, even though really of course it isn't, it's a # followed by the preprocessor instruction define. But since I do think of it that way, it seems wrong to separate them. I expect text editors written by people who advocate that style will have a block indent/un-indent that works on code written in that style. But I would hate to encounter it using a text editor that didn't.

There's no point pandering to ancient preprocessors where the # has to be the first character of the line, unless you can also list off the top of your head all the other differences between those implementations and standard C, in order to avoid the other things you could possibly do that they would not support. Of course if you genuinely are working with a pre-standard compiler, fair enough.

番薯 2024-08-20 20:05:35

预处理器指令是我们的程序中包含的行,它们实际上不是程序语句,而是预处理器的指令。这些行前面始终带有井号 (#)。“#”前后允许有空格。一旦找到换行符,预处理器指令就被认为结束。

就 C/C++ 标准而言,没有其他规则,所以它仍然是风格和可读性问题,我仅以您发布的第二种方式看到/编写了程序,尽管第三种方式似乎更具可读性。

Preprocessor directives are lines included in our programs that are not actually program statements but directives for the preprocessor. These lines are always preceded by a hash sign (#).Whitespace is allowed before and after the '#'. As soon as a newline character is found, the preprocessor directive is considered to end.

There is no other rule as far the standard of C/C++ concerned,So it remains as the matter of style and readability issue,I have seen/wrote programs only in the second way that you posted,although the third one seems more readable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文