include в хидере - всё таки это доро или зло?, Есть противоположные мнения, хочется понять их Опции

[Cosmojam]

Речь идёт про Си. Си++ не трогаем, хотя догадываюсь что аргументы там те же.

Существует мнение что писать в .h все необходимые инклюды - это плохо. Единственное подтверждение почему это плохо что мне удалось найти - время компиляции увеличивается. Многократные инклюды одного хидера лечатся очень просто с помощью ifndef/define и как аргумент не рассматриваются т.к. без защиты от множественных инклюдов в любом проекте где один хидер используется более чем в 1 .c файле будут проблемы.

Мой аргумент почему это стоит делать: Хидер - это заголовок модуля, определяющий его публичный интерфейс. Логично расположить в нём всё необходимое для работы модуля, а в .с файле инклюдить только один этот заголовок т.о. отделив реализацию от интерфейса. Улучшается наглядность т.к. сразу в хидере видно зависимости от других модулей.
Погуглив можно найти мнение со ссылкой на NASA C coding standard где написано

(4)
The unit header file shall contain #include statements for all other headers required by the unit
header. This lets clients use a unit by including a single header file.

Так как же "правильнее"? NASA не дураки ведь. Так почему существуют противоположные мнения?

[Сергей Борщ]

Хидер - это заголовок модуля, определяющий его публичный интерфейс. Логично расположить в нём всё необходимое для работы модуля, а в .с файле инклюдить только один этот заголовок

Да, действительно, заголовочный файл - интерфейс модуля. В него нужно включать через #include только те файлы, которые необходимы для этого интерфейса, для обращений к этому модулю. Чтобы в пустом .c - файле сделать #include "my_header.h" и это откомпилилось. Те заголовочные файлы, которые необходимы для реализации вашего модуля - его внутреннее дело, для обращений к модулю они не нужны и вытаскивать их в заголовочный файл не нужно и даже вредно (по причине увеличения времени компиляции и просто замусоривания заголовочного файла). А вы смешали эти две группы заголовочных файлов в одну.

[Cosmojam]

Да, действительно, заголовочный файл - интерфейс модуля. В него нужно включать через #include только те файлы, которые необходимы для этого интерфейса, для обращений к этому модулю. Чтобы в пустом .c - файле сделать #include "my_header.h" и это откомпилилось. Те заголовочные файлы, которые необходимы для реализации вашего модуля - его внутреннее дело, для обращений к модулю они не нужны и вытаскивать их в заголовочный файл не нужно и даже вредно (по причине увеличения времени компиляции и просто замусоривания заголовочного файла). А вы смешали эти две группы заголовочных файлов в одну.

Ок, а если, например, есть модуль A, для реализации которого (именно реализации) требуется модуль B. Но для использования A не обязательно инключить B.h в A.h (нет зависимости от объявленных в B.h типов и дефайнов). В этом случае получается include "B.h" надо писать в A.c. Но тогда взглянув на A.h нельзя точно сказать от каких модулей он зависит. Т.е. получает компромисс между читаемостью и захламлением глобального пространства имён.

А для решения проблем с переопределением одинаковых символов/функций можно к имени всех глобальных функций/символов добавлять префикс с именем модуля. Например, во FreeRTOS так сделано.
С точки зрения крупных проектов это нормально или тоже есть какие-то подводные камни?