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).
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
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.
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.