Поскольку народ настаивает...
Цитата:
Модульное программирование на языке Си возможно
Тут, конечно, хорошо бы более специфично указать, про какое именно модульное программирование идет речь. Ссылкой или хотя бы "как в языке X".
Цитата:
• На каждый модуль должен приходиться ровно один header-файл. Он должен содержать лишь экспортируемые прототипы функций, описания и ничего другого (кроме комментариев).
Сформулировано коряво, но "не буду придираться к словам". Не буду также упоминать, что есть довольно распространненная практика по более детальному делению хедеров в С++ на forward declaration, декларации классов и декларации определений шаблонов. Т.е. хередров будет более одного и ничего крамольного в этом не будет.
Цитата:
• Внешней вызывающей процедуре об этом модуле должны быть известны только комментарии в header-файле.
[1]
Еще более коряво. Но тоже можно догадаться чего имел ввиду автор. Однако суть правила не раскрыта. Использовать что-то, что не задекларировано в С невозможно и без всяких правил, это все-таки не динамический язык. Единственное исключение - вызов функции без прототипа, который специфичен только для С (не С++) и "правило" для которого описано ниже.
Цитата:
• Для проверки целостности каждый модуль должен импортировать свой собственный header-файл.
Какой целостности? Без контекста выглядит просто как пугалка. Не написал "#include" и все, никакой целостности? Тут мне не догадаться, бред 100%.
Цитата:
• Для импорта любой информации из другого модуля каждый модуль должен содержать строки #include, а также комментарии, показывающие, что, собственно, импортируется.
См. мой комментарий [1]. А касательно комментариев про то, что именно импортируется - похоже на личных тараканов автора, во всяком случае точно не общая практика.
Цитата:
• Прототипы функций можно использовать только в header-файлах. (Это правило необходимо, поскольку язык Си не имеет механизма проверки того, что функция реализуется в том же модуле, что и ее прототип; так что использование прототипа может маскировать ошибку «отсутствия функции» — «missing function»).
Бред 100%. Но можете попробовать переформулировать.
Цитата:
• Любая глобальная переменная в модуле, и любая функция, кроме той, что импортируется через header-файл, должны быть объявлены статическими.
Специфично для C. Для С++ для этого есть анонимный namespace. Опять же, что будет если не следовать этому правилу не поясняется. Потеря целостности?
На самом деле или ничего не будет или будет ошибка линковки.
Цитата:
• Следует предусмотреть предупреждение компилятора «вызов функции без прототипа» (function call without prototype); такое предупреждение всегда нужно рассматривать как ошибку.
Это предупреждение включено по умолчанию во всех современных компиляторах С. В С++ - ошибка. При том, что С++ делался с учетом максимальной обратной совместимостью с С можете представить насколько такой сценарий (вызов без прототипа) ненормален даже для С програм.
Цитата:
• Программист должен удостовериться в том, что каждому прототипу, заданному в header- файле, соответствует реализованная под таким же именем в том же модуле неприватная (т.е. нестатическая в обычной терминологии Си) функция. К сожалению, природа языка Си автоматическую проверку этого делает невозможной.
Неправда. При нарушении этого правила будет ошибка линковки. Да, компилятору будет пофиг, но программа не соберется. Опять пугалка.
Цитата:
• Следует с подозрением относиться к любому использованию утилиты grep. Если прототип расположен не на своем месте, то это, скорее всего, ошибка.
Это уже обсудили.
Цитата:
• В идеале программисты, работающие в одной команде, не должны иметь доступа к исходным файлам друг друга. Они должны совместно использовать лишь объектные модули и header-файлы.
Опять какие-то тараканы автора. Очень специфичный workflow, никак не общие правила.
Цитата:
Очевидная трудность в том, что мало кто будет следовать этим правилам, ибо компилятор не требует их неукоснительно соблюдать.
Опять же может быть прочитано как пугалка. Создается впечатление, что копилятор ничего не проверяет и все крэшается (никакой "целостности"), если не следовать этим "правилам". Это не так. На самом деле правила
могли бы пояснять правильную организацию кода в Си проекте. Если бы были нормально описаны.