关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
4年前关闭。
Improve this question
我已经做了一些搜索并咨询了我的一个 friend ，但也想得到 StackExchange 社区的意见。作为序言，我主要是一个陷入低级固件领域的硬件人，所以请原谅我任何看似常识的事情。我过去做过 C 编程，但已经有一段时间了。
对于自定义 ASIC，我们有许多控制/状态寄存器，我们将通过软件/固件访问这些寄存器(从现在开始我可能只会将其称为 SW)。对于我们的 verilog/SV/UVM 测试平台，我们有一个脚本来构建一个 verilog header `define 文件。在这种情况下，我们有以下结构:
`define REG_NAME <addr of register>
`define REG_NAME__BITFIELD1 <bit vector i.e. 1:0>
`deinfe REG_NAME__BITFIELD2 <bit vector i.e. 4:2>
我们使用双下划线在视觉上区分寄存器名称和位域。然后我们用它来做读-修改-写、屏蔽位等操作。对于软件，我写了一个脚本来打印 C 格式的 .h 文件。我想保持类似的格式:
#define REG_NAME <addr of register>
#define REG_NAME__BITFIELD1___MASK 0x00000003
#define REG_NAME__BITFIELD1___SHIFT 0
#deinfe REG_NAME__BITFIELD2___MASK 0x0000001c
#deinfe REG_NAME__BITFIELD2___SHIFT 2
在这种情况下，我想保留双下划线以区分 REG 和 BIT_FIELD 和三元组以区分 MASK/SHIFT/我添加的任何其他内容。
我知道基于以下 SE 问题:
Use of double underscore in C
How is __mro__ different from other double underscore names?
带前缀的下划线不是一个好的编码习惯。像这样在定义的内部使用双/三下划线通常是一种糟糕的编码习惯吗？我知道我可以控制宏定义从不以双下划线/三下划线开头或结尾。老实说，这对我很有帮助。当使用所有单个下划线时，我很难找出单词之间的差异。并且有超过 60k 个基于寄存器的 #defines，我想有一个更清晰的方式来看待它。然而，如果这是大多数软件工程师会讨厌的东西，我会改变它，因为迟早(希望)真正的软件工程师会处理大部分问题(不是说我介意做软件，这很有趣)。
如果已经讨论过这个问题，请随时转发线程。我搜索了大约 30-45 分钟，但找不到任何似乎完全讨论这个话题的内容。
谢谢!
最佳答案
在 C 和 C++ 中，您(应用程序程序员)应该避免以单个下划线开头的标识符——至少在某些上下文中，所有这些标识符都是“为实现保留的”；与其记住确切的规则，不如坚持以字母开头所有标识符。
在 C++ 中 只有 ，包含两个连续下划线的标识符(如您的 REG_NAME__BITFIELD1___MASK )也保留用于实现。
所以，就标准而言，你可以用C做你想做的，但是不是 在 C++ 中。
就风格而言，我个人认为您想要连续使用两个下划线的理由(许多类似的标识符在其名称中有结构，使结构更加明显)是合法的，我不同意链接的问题谁说阅读时很难分辨一个和两个下划线之间的区别。不过，我不明白你为什么要连续三个下划线，而且我确实认为很难区分连续两个和三个下划线之间的区别。
(注意:您链接到的一个旧问题是关于 Python，它是一种完全不相关的语言；它不能用于得出关于 C 或 C++ 的结论。)
(您可以使用以下划线开头的实现定义的标识符，只要它们被记录在案——例如 __STDC__ 、 _Bool 、 _IOLBF —— 只是不要自己定义它们，除非文档特别告诉你来定义它们(例如 _POSIX_C_SOURCE )。在复杂的程序中，“程序”和“实现”之间的界限会变得模糊，所以如果你看到一个定义以下划线开头的标识符的程序，不要害怕；有作者确切地知道他们在做什么的好机会。)
关于C - #define 宏内的双下划线，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43461615/