Hi Ingo,
I submitted this proposal a while ago, so I would like to make sure that it is
submitted to the style committee as a formal proposal.
The implementation strategy would be to change all guards that do not conform,
and add guards where those are missing.
I leave to the committee to decide whether the include guard should end in _H or
_INCLUDED, but I suggest that it takes the comment by Kristian into consideration.
Best wishes,
Mats Kindahl
Mats Kindahl wrote:
>
> Kristian Nielsen wrote:
>> Mats Kindahl <mats@stripped> writes:
>>
>>> I have a proposal for rules regarding the naming and usage of include guard.
> I
>>> see currently in the code include guards missing, but also used in odd ways
> that
>>> makes it more difficult to automatically check header files for missing
> include
>>> guards.
>> Sounds good!
>>
>>> - Include guards shall be of the form ``PACKAGE_HEADER_INCLUDED``,
>>> that is: the package name followed by the base file name (excluding
>>> the extension) in all capital letters, numbers, and underscores. The
>>> package name and the header name is separated by an underscore.
>>> The extension is omitted because there are different naming
>>> conventions (.h, .hh, .hpp) and the choice of naming convention for
>>> header files should not affect the include guard name.
>> $ find . -name '*.h' -o -name '*.hpp' -o -name '*.ic' | xargs egrep
> '^#define.*_H'|wc -l
>> 1735
>> $ find . -name '*.h' -o -name '*.hpp' -o -name '*.ic' | xargs egrep
> '^#define.*_INCLUDED'|wc -l
>> 9
>>
>> Please do not change the existing code style without good reason. Clearly the
>> current style is using _H, not _INCLUDED, and _H will be as easy for
>> developers to undestand as _INCLUDED, no matter the name of the file.
>>
>> So let's keep PACKAGE_HEADER_H, please?
>
> Given the number of include guards in the *_H format, it makes sense.
>
> Thanks for the feedback.
>
> /Matz
>
>> Thanks,
>>
>> - Kristian.
>
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
