Как соблюсти ПРАВИЛА ХОРОШЕГО ТОНА при написании программ на Си?, (Как компоновать проект? Что оставлять в xxx.c, а что в xxx.h ?) Опции

[kv_addr]

Написал было объемистое предисловие, но Фаерфокс глюкнул и оно исчезло, поэтому обойдусь без него.

Перешел с ассемблера на Си, создал ряд проектов, работающих, но так и не получил четкого представления о том, как нужно оформлять программу на Си по ПРАВИЛАМ. Может сказалась былая практика программирования на Фортране и Паскале. Наибольшее непонимание у меня вызывает то, что нужно оставлять в xxx.c, а что выносить в xxx.h. Виной тому - ужасная чересполосица в куче разных сторонних проектов, которые довелось разбирать в процессе освоения Си. В одних проектах водораздел один, в других - совсем иной. И даже в атмеловских аппноутах - тоже полный разнобой.

Пользуюсь IAR EWAVR-ом.

Вот пара примеров написания программ, с которыми встречался:
Имеются: основной модуль - xxx.c, хедер к нему - xxx.h, пара модулей - yyy.c, zzz.c и хедеры к ним yyy.h, zzz.h.

Первый вариант организации проекта. В проект подключен основной модуль xxx.c, в котором в самом начале подключен при помощи директив #include необходимый набор стандартных библиотек, хедер xxx.h, а также два дополнительных модуля yyy.c и zzz.c. В самих модулях yyy.c и zzz.c при помощи этих директив подключены yyy.h и zzz.h соответственно. В основном модуле располагается главная программа и набор функций, относящихся непосредственно к ней. В хедере располагаются глобальные определения, описания глобальных переменных и констант, а также прототипы функций основного модуля. В дополнительных модулях располагаются функции модулей, а в хедерах дополнительных модулей располагаются определения, переменные, константы и прототипы, касающиеся этих модулей.


Во втором варианте организации проекта дополнительные модули включены в проект подобно основному. В основном же модуле при помощи #include подключены yyy.h и zzz.h. Также они подключены с помощью этой директивы и в yyy.c и zzz.c соответственно.

Оба проекта полностью рабочие, потому как в конечном счете все полностью завязано и в первом и во втором случае.

Встречался также с вариантами написания программ, где, например, описания переменных вынесены в ***.c вместо ***.h.

Имею два конкретных вопроса:

1. КАК нужно подключать в проект модули и хедеры согласно ПРАВИЛ ХОРОШЕГО ТОНА написания программ на языке Си?
2. ЧТО нужно согласно тех же ПРАВИЛ выносить в ***.h, а что оставлять в ***.c?

Четкого, внятного, однозначного ответа я так и не нашел. Хотелось бы узнать мнение уважаемого сообщества.

PS: Конечно, можно компоновать как попало, имея в результате полноценный рабочий код, но вопрос в том, как общепринято ПРАВИЛЬНО это выполнять?

[MrYuran]

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

Очень упрощает жизнь не только другим, но и себе, когда спустя несколько лет смотришь в код и соображаешь - ё-моё, чтож я сделал-то?!

[zltigo]

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

Люди не компьютры - шаблонное, дежурное, формальное доксигеновское комментирование есть тупость и зло, зачастую не меньшее, чем полное отсутствие комментариев.

Также я во всех проектах создаю файл includes.h, который включен во все *.с, больше никаких include в с-файлах..

Лобовое неразумное решение приводящее к созданию лишних зависимостей и скрывающее суть проекта от человека. Некоторые хидеры могут объединяться в общие логические группы, пусть и несущие небольшую избыточность, но огульное сваливание всего в одну кучу....

[Dog Pawlowa]

Лобовое неразумное решение приводящее к созданию лишних зависимостей и скрывающее суть проекта от человека.

Еще и время компиляции увеличивается, поскольку весь проект будет перекомпилирован при корректировке любого h-файла.

[Legotron]

Еще и время компиляции увеличивается, поскольку весь проект будет перекомпилирован при корректировке любого h-файла.

Согласен, увеличивается.. недостаток
Зато не надо вспоминать, "какие же h-ники мне нужны в этом c-файле?" или компилировать до тех пор, пока компилятор не прекратит ругаться на отсутствие h-файлов, добавляя их по одному

[Dog Pawlowa]

Зато не надо вспоминать ...

Признаться, я сам использую комбинированный способ

Но на самом то деле при грамотном проектировании сверху вниз обеспечивается иерархия файлов/уровней взаимодействия, и количество включаемых файлов не так то и велико.

[zltigo]

Признаться, я сам использую комбинированный способ

Это нормально, вот например, некий файл "rtos.h" у меня в него включены в том числе несколько *.h индивидуальных под контроллер и проект конфигурационных файлов и всякие парные *.c "queue.h", "task.h" и так далее. Система меняется относительно редко, избыточность включения небольшая, логически все достаточно связано.