Включить стратегию упорядочения файлов

Question

Я видел довольно последовательный совет, что файл реализации (.cc / .cpp) должен включать соответствующий ему файл определения класса первый , прежде чем включать другие заголовочные файлы. Но когда тема переходит к самим заголовочным файлам, и порядок включений в них содержится, совет кажется другим.

Стандарты кодирования Google предлагают:

1. dir2 / foo2.h (предпочтительное расположение - подробности см. Ниже).
2. C системных файлов.
3. C ++ системные файлы.
4. Файлы других библиотек .h.
5. Файлы вашего проекта .h.

Неясно, в чем разница между пунктами 1 и 5 выше и почему будет выбрано одно или другое местоположение. Тем не менее, другой онлайн-справочник предлагает следующий порядок (находится в разделе «Схема классов» этого документа):

1. Система включает в себя
2. проект включает в себя
3. местные включают

Еще раз возникает двусмысленность, на этот раз между пунктами 2 и 3. В чем различие? Представляют ли они межпроектные и внутрипроектные включения?

Но, более конкретно, похоже, что оба предложенных стандарта кодирования предполагают, что "ваши" заголовочные файлы включены последними. Такой совет, будучи обратным тому, что рекомендуется для включения порядка в файлах реализации, не является интуитивно понятным. Разве не имеет смысла, чтобы «ваши» заголовочные файлы последовательно перечислялись первыми - впереди системных и сторонних заголовков?

Answer 1

Я не знаю ни одного стенографического стандарта, но, как правило, включаю как можно меньше заголовков, особенно в другие заголовочные файлы, чтобы сократить время компиляции, конфликты и зависимости.Я фанат использования предварительного объявления классов в заголовочных файлах и только включаю заголовок и определение на стороне .cpp всякий раз, когда я могу себе это позволить.

При этом мои личные предпочтения ниже:

Для заголовков:

1. Заголовки C ++
2. Заголовки сторонних разработчиков
3. Заголовки других проектов
4. Заголовки этого проекта

Для источника:

1. файл скомпилированного заголовка
2. заголовок этого исходного файла
3. заголовки C ++
4. сторонние заголовки
5. другие заголовки проекта
6. заголовки этого проекта

Указатели или предложения обычно позволяют избежать конфликтов и циклических ссылок, в противном случае это все личные предпочтения или политика, которую вы предпочитаете придерживаться для совместных проектов..

Answer 2

Относительно стиля Google:

Нет никакой двусмысленности.

Первый включенный заголовок должен быть заголовком, относящимся к this исходному файлу, то есть в позиции 1. Таким образом, вы убедитесь, что он включает в себя все, что ему нужно, и что нет «скрытой» зависимости: если она есть, она сразу разоблачатся и предотвратят компиляцию.

Остальные заголовки заказываются из тех, которые вы с наименьшей вероятностью сможете изменить, если возникнет проблема с теми, у кого вы с большей вероятностью. Возможно, проблема связана с конфликтом идентификаторов, утечкой макросов и т. Д. *

По определению заголовки систем C и C ++ изменяются очень редко, просто потому, что их используют очень много людей, поэтому они идут вторыми.

Сторонний код может быть изменен, но обычно он громоздок и требует времени, поэтому они идут третьим.

«Проект включает» относится ко всем проектным включениям, обычно домашним библиотекам (промежуточное программное обеспечение), которые используются несколькими проектами. Их можно изменить, но это повлияет и на другие проекты, они идут четвертыми.

И, наконец, «локальные включения», то есть те файлы, которые относятся к этому проекту и могут быть изменены без влияния на кого-либо еще. В случае возникновения проблемы это первичные кандидаты, они идут последними.

Обратите внимание, что на самом деле вы можете иметь гораздо больше слоев (особенно в магазине программного обеспечения), ключевая идея состоит в том, чтобы упорядочить зависимости, начиная с нижнего уровня (системные библиотеки) до верхнего уровня.

Внутри данного слоя я склонен упорядочивать их по алфавиту, потому что их легче проверять.

Answer 3

Порядок, который вы включаете в список, не должен иметь значения с технической точки зрения.Если вы спроектировали это правильно, вы сможете разместить их в любом порядке, и вы все равно будете работать.Например, если вашему foo.h нужен <string>, он должен быть включен в ваш foo.h, чтобы вам не приходилось запоминать эту зависимость везде, где вы используете foo.

.у вас do есть зависимости порядка, большую часть времени оставляя ваш файл определения последним, это исправит.Это потому, что foo.h зависит от <string>, но не наоборот.

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