ifndef中的下划线是怎么回事

现在怎么办？



      以下为原文

    Now what?

我猜不同的人写的代码，没有一个编码标准，或没有遵循。



      以下为原文

    I'm guessing different people wrote the code and there isn't a coding standard, or it wasn't followed.

是的，虽然用户通常不鼓励使用领先的下划线，但在“包含警卫”中，他们总是存在于微软C包含文件中。只是一种习惯，可以这么说



      以下为原文

    Yeah,
though users are usually discouraged from using a leading underscore, in "include guards" they were always there in Microsoft C include files. Just a habit, so to say

对于包含后卫，我也遇到了一种带有前导加后跟下划线的风格（＝＝& gt；yfvrthHi）。意图不是与“通常”定义的冲突（如果你通常不使用领先的下划线，那么完美）。



      以下为原文

    For include guards I also encountered a style with a leading plus a trailing underscore (==> _FVR_H_).
The intention is not to collide with "usual"  #defines (perfect if you're usually not using leading underscores).

嗨，领先的下划线是一种尝试避免命名冲突的方法，也就是为了避免相同的符号被用于不同目的的问题。该约定是“系统库”使用宏符号的领先下划线，因此应用程序代码和应用程序库代码应该使用MACR。o不从下划线开始的符号。MCC生成的代码是否应被视为“系统代码”或“应用程序代码”，可能会引起争论，但代码生成的MCC与预期使用的编译器一起测试，因此编译器所使用的符号之间存在任何冲突，MCC使用的符号应该已经解决了。设备支持头文件，使用带有用于寄存器位和字段的宏符号的领先下划线的符号，但是SFR寄存器名没有下划线，因此SFR寄存器名在没有领先下划线的情况下保留了许多保留名称。这些都是大写的名字，除了PIC32 MIPS系统协处理器CP0中的几个寄存器，但是这些寄存器无论如何都不能被C代码直接访问。迈西尔



      以下为原文

    Hi,
The leading underscore is a way to try to avoid naming conflicts,
that is to avoid problems by the same symbol beeing used for different purposes.
 
The convention is that 'system libraries' use a leading underscore for macro symbols,
so application code and application libraries code should use macro symbols that do not start with underscore.
 
Whether code generated by MCC should be regarded as 'system' code, or 'application' code,
may be open to debate, but code generated MCC is tested together with the compiler that is expected to be used, so any conflict between symbols used by the compiler, and symbols used by MCC should have been solved already.
 
Device support header files, use symbols with a leading underscore for macro symbols for register bits and fields,
but SFR register names have no underscore, so SFR register names make a lot of reserved names without a leading underscore. These are mostly all uppercase names, except a few registers in PIC32 MIPS system coprocessor, CP0, but those registers cannot be accessed directly by C code anyway.
 
   Mysil
 
 

谢谢你，Mysil。我想从我的新手角度来看，我会努力使所有文件都能保持一致。看起来最好的做法是在两端不要使用下划线。



      以下为原文

    Thank you Mysil.
 
I guess from my newbie viewpoint I'll just try to make it consistent across all my files. It looks as though a best practice might be to not use the underscores at either end. 

从{下划线}{下划线}或{下划线}{大写}开始的标识符被保留以供实现者使用。用户保证所有非保留的标识符都可以在自己的代码中使用。我们是Implementer，你是用户。在我们提供的源代码中出现了棘手的问题，这可能是由你修改的。在我的卑微（哈！）MPLAX生成的头文件骨架，当你告诉它在你的项目中创建一个新的头文件时，你要填写的是用户代码，因此它们的包含保护不应该有领先的下划线；由MCC等产生的“驱动”，被用来作为IS，实现。R代码及其包含的警卫应该有领先的下划线；任何与上面不匹配的是bug，你应该记录一个支持TIKETE来修复它。



      以下为原文

   


Identifiers beginning with {underscore}{underscore} or {underscore}{uppercase} are reserved for use by the Implementer. The User is guaranteed that all non-reserved identifiers are available for use in their own code.
We are the Implementer, you are the User.
 
The tricky bit arises in source code that we supply that is perhaps intended to be modified by you.
 
In My Humble (hah!) Opinion,

• header file skeletons generated by MPLAB X when you tell it to create a New Header file in your project, intended to be filled out by you, are User code and so their include-guards should not have leading underscores;
  
• "drivers" generated by MCC etc., intended to be used as-is, are Implementor code and their include-guards should have leading underscores;
  

and anything not matching the above is a bug and you should log a support ticket to get it fixed.

请注意，当使用“文件/新文件”创建一个新的.h文件时，它不会自动使用下划线。因此，在这种方式下，它通常被MLP、MysIL和其他人在这个线程中推荐。



      以下为原文

    Just a note to say that when creating a new .h file using "File/New File" it does not automatically use underscores.  So in this way it works as has been generally recommended by mlp, mysil and others in this thread.