Not so long ago I started the discussion about pragma’s and include-guards. This has given me a lot of contradictory opinions. But the discussion itself has not finished with any conclusion.
Recently I have read it again and I hope I have found some compromise solution for that. I still (ridiculously) propose the change of include-guard style because I am working more on refactoring of the project and I am annoyed by checking and fixing the coherence between file path and include-guard name.
I agree that #pragma once is not standard and it should not be used in such projects.
I agree that 3 lines of code is not as noisy as I asserted before.
But it still bothers me to set valid names for include-guards (IDE often can’t help with this).
I propose to change Coding Standards/Header Guard and allow to use GUID (UUIDv4) as include-guard names. This change is suppose to:
Make easier to move/rename files;
Make it possible to ‘set-and-forget’ about include-guard (means not change anymore);
Make sure that each header have unique include-guard (collisions is not possible anymore);
Make easier to find a particular header since it is uniquely identified.
The actual format of identifier is for discussion. But I can propose some variants:
#define IG_3f1ae4ee_eabb_44a2_b2a7_9d745a551c1e // IG prefix means Include Guard
#define _6312D971_13CE_4091_9F9E_9176F6B413B5_ // With underscore prefix and suffix
#define B47BE2C1_3E12_4B4D_9C2C_83D9FFD09AC5 // Do not use GUIDs with leading digit
#define B47BE2C13E124B4D9C2C83D9FFD09AC5 // Without separators
Named include-guards are used now according to Coding Standards/Header Guard. It is pretty annoying to deal with if you move/rename files a lot.
We can NOT use #pragma once named or unnamed because it is not a standard feature of C/C++, even though it is supported in all compilers that are able to compile LLVM.
The aim of this proposal is to decouple the name of file and header-guard. If you overthink about readability of header-guards, ask yourself, how often do you read them?
It’s really very hard to come up with an easier process for naming header guards uniquely than (a) look at the path, (b) type it in uppercase with punctuation changed to underscores.
This is the only true plus, and matters only to people who do that kind of refactoring a lot. To everyone else, header guards are part of the boilerplate, like the license comment.
This is redundant with the first point.
Guard names that follow the standard are already unique.
Who ever needs to find a header based on the guard name? And if I did, reading the library/path/filename off the header is a lot more direct than having to grep for some string of random characters.
Downsides:
Creating a new header becomes more complicated, because I have to go through some process to generate the un-obvious guard name.
The web page with the instructions for generating the new guard name will not be easy to find. (Yeah, I know it will be on the coding-standard page. That’s why I know it won’t be easy to find, because it always takes me a while to find it.)
I probably don’t have the tool installed.
Doubtless people will think I’m complaining unnecessarily about trivial things, but you’ll need to explain how the new process will be less trivial than the old scheme described at the top of my post.
I’d like to suggest an alternative solution to make life easier for someone like you, who has to deal with a lot of include guard renaming. Why not create a script that checks the include guard names and corrects them? This script could be utilized as a pre-commit Git hook, making it as seamless as clang-format. Additionally, it’s possible that clang-format or clang-tidy could be enhanced to verify and rectify the include guards.