4

I figured one of the best ways I could learn and improve in programming is to look at various source codes. I was looking at Blender's source code and noticed something about the header files. Most of them used #ifndef include guards, where macros were surrounded by double underscores (e.g. __BMESH_CLASS_H__).

It got me thinking, the whole "just don't make anything that starts with underscores at all" advice is good for beginners, but I would think that in order to progress further in programming I should learn when creating my own reserved identifiers is and isn't appropriate.

thepufferfish
  • 441
  • 4
  • 17
  • 2
    related for c: https://stackoverflow.com/questions/17307540/include-guard-conventions-in-c – Hulk Apr 15 '20 at 08:23
  • 2
    and for c++: https://stackoverflow.com/questions/4867559/naming-include-guards – Hulk Apr 15 '20 at 08:24
  • 7
    It's never appropriate, and Blender does it wrong. Most code is formally wrong in several ways, sometimes because "it works, and I can't be bothered". – molbdnilo Apr 15 '20 at 08:34
  • If somebody considers making an answer along @molbdnilo comment but is worried... I am convinced this is **not** opinion-based and I promise to upvote. – Yunnosch Apr 15 '20 at 08:37

2 Answers2

6

I would think that in order to progress further in programming I should learn when creating my own reserved identifiers is and isn't appropriate.

Reserved identifiers are reserved for the implementation, which means roughly the compiler, its runtime library, and maybe parts of the operating system.

So, it's appropriate to create your own when your progression has led to you writing your own compiler or operating system. That's pretty much it.

Useless
  • 64,155
  • 6
  • 88
  • 132
4

There is only one case I know of where reserved identifiers are allowed to be self-made. All others are considered undefined behavior, and while they will still most likely work completely the same, it's against the standard and shouldn't be done.

That said, reserved identifiers can be made by you when interacting with certain components of your development environment. For example, some compilers may support something like __FILE_NAME__ and others may not, and it may even vary from compiler version to compiler version. If you are making it yourself for, say, backwards compatibility (i.e. adding a preprocessor definition to define said macro), then it is 100% okay, so long its implementation follows the requirements of what is expected of using said identifier exactly (e.g. it should substitute to the file name for __FILE_NAME__, not something else).

nowi
  • 437
  • 4
  • 13
  • 2
    I wouldn't define `__FILE_NAME__` on platforms that don't *currently* define it. I would conditionally define `FILE_NAME` to be `__FILE_NAME__` where available, and the workaround otherwise. – Caleth Apr 15 '20 at 08:58