лучшие практики для заголовочных файлов C с #ifndef #define #endif

Назовите их BLAFOO_H (лично я использую BLAFOO_H_ , где BLAFOO - имя файла заголовка).

Убедитесь, что ваш BLAFOO не конфликтует с другими файлами / библиотеками / и т. Д. вы используете, например имя вашего проекта и / или модуля должно быть частью этого имени.

Идентификаторы, начинающиеся с _ , зарезервированы для реализации / компилятора, поэтому не используйте их.

На самом деле это не имеет значения, если оно не будет использоваться где-либо еще. Обычно я использую что-то вроде BLAFOO_H_INCLUDED .

Я использую UUID, который является моей гарантией того, что #define не сцепится с другими. Я где-то видел это и решил тоже использовать.

Мой шаблон выглядит следующим образом: ___H___,

eg. #define __TYPES_H_79057761_16D6_478A_BFBC_BBF17BD3E9B9__ для файла с именем types.h

Единственным реальным требованием является то, что он не будет конфликтовать с другим проектом, который использует такое же имя для своего файла. Во всех проектах, которые я видел, обычно полностью указывается пространство имен (или папка, в которой находится файл для C) вместе с именем проекта. Иногда он включает и дату создания файла.

Так что если вы работаете над проектом ABC в папке DEF сегодня, то вы можете сделать:

#ifndef ABC_DEF_BLAFOO_H_05_30_2010

И это вряд ли будет с чем-то конфликтовать.

Как и в других вопросах в стиле C, просто будьте последовательны. Вы никак не сможете узнать пространство имен каждой библиотеки, которую кто-то может связать с вашей программой в будущем. Почему? Многие из них еще не написаны :)

Таким образом, это не вопрос об охране include, это вопрос о том, как назвать заголовок в первую очередь.

Я могу придумать несколько новых классных строковых утилит и назвать заголовок strutil. Это плохая идея, потому что (наверняка) кто-то другой придумал новые классные утилиты для работы со строками и назвал заголовок так же.

Итак, я называю свой post_strutils.h и:

#ifndef POST_STRUTILS_H
#define POST_STRUTILS_H
/* code */
#endif

Я могу даже назвать его post_str_utils.h и соответствующим образом определить include guards, потому что я знаю, что у меня очень распространенная фамилия. Найти пространство имен иногда бывает непросто. Простое использование такого пространства не дает гарантии, что кто-то другой провел поиск, прежде чем выпустить что-то в свободный доступ. Будьте настолько уникальны, насколько это возможно.

В зависимости от того, где кто-то указывает компилятору искать заголовки, возникают конфликты не только пространств имен, но и имен файлов. Сделайте все возможное, чтобы назвать заголовок уникально, а затем напишите включающий защитник в соответствии с этим. Кто-то может захотеть #error, если заголовок был включен несколько раз, хотя бы для того, чтобы отсечь ненужные директивы #include. Использование UUID несколько запутывает процесс, поскольку он не совпадает (или даже не похож) на имя файла рассматриваемого заголовка. Это также усложняет написание скриптов grep/awk (или подобных), работающих по принципу lint.

Я не говорю, что вы должны называть каждую библиотеку / модуль в честь себя, но позаботьтесь о том, чтобы имена открытых заголовочных файлов были уникальными. Быстрая конференция с поисковой системой подскажет вам, не попали ли вы в неиспользуемое пространство имен. Пожалуйста, пусть включаемые защитные элементы совпадают (или, по крайней мере, очень похожи) с заголовком. Опять же, согласованность заслуживает высокой оценки. Судя по вашему примеру, я бы ожидал:

int blahfoo_init(void);
double blahfoo_getval(blahfoo_t *blah);

Если вы потрудились найти уникальное пространство имен, обязательно используйте его :)