Я знаю, что это мало чем отличается от проекта, но, предполагая, что вы используете #defined защиты заголовка для вашего кода на С++, какой формат вы используете? например предполагая заголовок с именем foo.hpp:
#ifndef __FOO_HPP__
...
#ifndef INCLUDED_FOO_HPP
...
#ifndef SOME_OTHER_FORMAT
Я продаюсь по идее прописных #defines, но не могу установить формат для этих охранников.
Я всегда включал пространство имен или относительный путь в include guard, потому что только одно имя заголовка оказалось опасным.
Например, у вас есть большой проект с двумя файлами где-то в вашем коде
/myproject/module1/misc.h
/myproject/module2/misc.h
Итак, если вы используете согласованную схему именования для ваших включенных охранников, вы можете в конечном итоге иметь _MISC_HPP__, определенный в обоих файлах (очень забавно найти такие ошибки).
Итак, я поселился с
MYPROJECT_MODULE1_MISC_H_
MYPROJECT_MODULE2_MISC_H_
Эти имена довольно длинные, но по сравнению с болью двойных определений это того стоит.
Другой вариант, если вам не нужна независимость от компилятора/платформы, вы можете искать некоторые вещи #pragma после.
Я всегда использую INCLUDED_FOO_HPP
Я бы не использовал двойной подчеркивающий, потому что начинаются вещи с двойными подчеркиваниями.
Чтобы действительно избежать конфликтов имен, я использую GUID:
#ifndef GUARD_8D419A5B_4AC2_4C34_B16E_2E5199F262ED
Лично я просто использую имя файла FOO_HPP. Google использует весь путь, такой как SRC_ENGINE_FAST_HPP.
Некоторые наборы имен и функций подписи всегда зарезервированы для реализация:
- Каждое имя, содержащее двойной знак подчеркивания (_ _), или начинается с подчеркивание, за которым следует верхний регистр письмо (2.11) зарезервировано для для любого использования.
- Каждое имя, начинающееся с символа подчеркивания, зарезервировано для реализации для использования в качестве имени в глобальное пространство имен.
(17.4.3.1.2/1)
Я предпочитаю этот формат:
#ifndef FOO_HPP
#define FOO_HPP
/* ... */
#endif // FOO_HPP
MYLIB_FOO_HPP, и это помогает избежать конфликтов имен.Если вы используете Visual Studio или компилятор Microsoft, используйте метод pragma
#pragma once
Я использую
#if !defined(FOO_HPP_INCLUDED)
Я предпочитаю современный синтаксис defined, потому что он позволяет || && операторов, даже если они здесь не используются.
Кроме
#ifndef __FOO_HPP__
является технически незаконным, так как ведущие символы подчеркивания зарезервированы.
Я всегда использую
#ifndef FOOBAR_CPP
Я также всегда использовал что-то вроде:
#ifndef FOO_HPP
#define FOO_HPP 1
...
#endif
Как упоминалось большинство людей, не добавляйте символы с двойными подчеркиваниями, как это зарезервировано стандартом С++ для внутреннего использования при реализации.
Вам может понравиться отличная книга Джона Лакоса "Разработка программного обеспечения большого масштаба С++" (ссылка Amazon - дезинфицирована для script kiddy link nazis) для некоторых соображений, касающихся заголовка.
НТН
веселит,
Rob
Когда мне платят за мое время, и еще нет стандартного для компании, я использую:
#ifndef path_to_file_h
#define path_to_file_h
Причиной для строчной буквы является то, что проще копировать и вставлять имена файлов и заменять косые черты символами подчеркивания. Причиной для #ifndef является то, что он хорошо сочетается С#define, что упрощает просмотр символов одинаковыми. Мне нравится идея GUID, поэтому я могу попробовать.
Когда мне не платят за мое время, и не выпуская мой код в дикую природу, я просто использую #pragma once. В отличие от большинства других проблем с переносимостью, их так же легко добавить, как и теперь, защищать их, и это может сделать кто-то, кто ничего не знает о базе кода (например, меня через год или какого-то невинного программиста, на который я отправляю свой код), поэтому применяется YAGNI.
Я обычно использую:
#ifndef FILE_DATE_H_
(замените _H_ соответствующим расширением, таким как _HPP_ и т.д.). Печать даты должна избегать столкновений с другими именованными заголовками в других направлениях/библиотеках.
поэтому в конце он выглядит следующим образом:
#ifndef SOMEFILE_20082411_H_
Я использую
<FILENAME_IN_ALL_CAPS>_<YYYYMMDD>
или
<FILENAME_IN_ALL_CAPS>_INCLUDED_<YYYYMMDD>
Сохранение синхронности с иерархиями папок слишком раздражает (друг рефакторинга), GUID слишком раздражает, суффикс даты достаточно хорош. Если бы я был в одинаковом названии файлов в тот же день, я бы
<FILENAME_IN_ALL_CAPS>_<YYYYMMDD>a
<FILENAME_IN_ALL_CAPS>_<YYYYMMDD>b
<FILENAME_IN_ALL_CAPS>_<YYYYMMDD>...
Я бы пошел с файловым движением + суффикс boost _INCLUDED плюс широко поддерживаемый в настоящее время #pragma once
В alot редакторах (для меня его возвышенное) вы также можете определить некоторые макросы/фрагменты для этого.
Вот один из них для вас:
<snippet>
<content><![CDATA[
#ifndef ${1:${TM_FILEPATH/(.*\/(include|src))*([^a-zA-Z0-9_]+)*([a-zA-Z0-9_]+)([.])*([a-zA-Z0-9_]+)*/\U$4_$6/ig}_INCLUDED}
#define $1
#pragma once
$0
#endif // $1
]]></content>
<tabTrigger>incguard</tabTrigger>
<description>include guard</description>
</snippet>
so yourproject/include/yourlib/yourfile.hpp
становится YOURLIB_YOURFILE_HPP_INCLUDED
Дополнительный инструмент проверки стиля внешнего исходного кода может легко отслеживать последовательность ваших охранников таким образом.